PostgreSQL Trezor Performance

Niektore trezory na PostgreSQL maju prehnane pomalu vykonnost pri selectovani dat. Selecty trvaju dlho (radovo v minutach) ci uz priamo z pgAdmina alebo z HI.
U zakaznika mame momentalne trezory TEDIS_TREZOR_1 az TEDIS_TREZOR_18.

Trezory od #1 po #7 su rocne trezory importovane zo Sybase (prvy a posledny maju mensi interval) a maju velkost okolo 170GB.
Trezory #8 a #9 su posledne 2 mesiace roka 2018 (12GB a 13GB velkost). Trezory od #10 a vyssie su z tohto roka s periodou 1 mesiac (velkost od 15GB do 20GB). Uvadzane velkosti su velkosti celej databazy vratane indexov.

Trezory od #9 vyssie su generovane automaticky systemom D2000.

Problem nastava pri vyberani z trezorov tohto roka (#10 a vyssie). Jednoduchy select trva niekde od 5 do 20 minut. Ked rovnaky select vykonam na najvacsom trezore (170GB), prejde to za 10-20 sekund. Na trezoroch 8 a 9 do 1 sekundy.

Vsimol som si, ze tie trezory 8 a 9 maju clustered index, tak som to skusal na tych novsich zmenit, skusali sme aj REINDEX TABLE a VACUUM ALL, ale nic nepomohlo, vykon je stale extremne pomaly.

Prosime o prioritne riesenie, blokuje nam to vyvoj projektu. Dakujem.

Dobrý deň.

Pozrite si: https://doc.ipesoft.com/label/D2DOCSK/trezorove_databazy

na konci tej stranky je:

Príklad dávkového súboru, ktorý slúži na upratanie a export trezorov po ich odpojení ako aj na export tabuľky trezors z archívnej databázy MyApp.Archiv. Dávkový súbor vyžaduje ako parameter názov trezorovej databázy, čo dosiahneme nastavením parametra TrezorPostCompressPar na hodnotu #TREZOR#.

a robia sa tam 4 veci (pred samotnym exportom):

  • povolenie pristupu na zapis do trezorovej databazy:

rem permit write access to depository database and cluster the data table
echo alter database “%1” set default_transaction_read_only=false | psql -S -U postgres MyApp.Archiv >> %MyDir%%1.log

  • zapnutie clustrovania podla indexu

echo alter table data cluster on ix_data_rc | psql -S -U postgres %1 >> %MyDir%%1.log

  • samotne clustrovanie (niekolko minut az hodin podla velkosti DB a rychlosti HDD)

echo cluster data | psql -S -U postgres %1 >> %MyDir%%1.log
rem set access to depository database back to read only

  • opätovné nastavenie prístupu iba na čítanie

echo alter database “%1” set default_transaction_read_only=true | psql -S -U postgres MyApp.Archiv >> %MyDir%%1.log

Vyskusajte to (najskor rucne na nejakom trezore). Bolo by dobre zabezpecit, aby archiv do toho trezoru pocas toho nesiel (lebo bud to zlyha alebo to zasekne tu pracu), preto ho DISMOUNT-ujte.
Ale ked je dismountovany, tak je zakazany pristup k databaze (vid vyssie v tom istom dokumente:

update pg_database set datallowconn = false where datname = ‘APLIKACIA_TREZOR_#ID#’

Takze vy este rucne musite vykonat
update pg_database set datallowconn = true where datname = ‘APPLICATION_TREZOR_#ID#’
aby ste sa tam vobec vedeli pripojit.

Potom to viete automatizovat tym, ze to date do takehoto bat-aku, ktory je spustany v ramci TrezorPostCompressCmd. A do TrezorCompressOffline date hodnotu 2 - podla manualu:

Hodnota 2 znamená, že D2000 Archív nebude do trezoru pristupovať, kým sa vykonáva TrezorPostCompressCmd,takže je možné, aby tento príkaz vykonával rôzne operácie údržby, ktoré by inak mohli archív zablokovať.

Takto to mame nakonfigurovane na par miestach. Takze archiv, ked prestane trezor pouzivat, tak si oznaci, ze teraz sa donho nepristupuje (ale nezakaze don pristup), spusti ten prikaz TrezorPostCompressCmd, trezor sa vam uprace a ked upratovanie skonci, archiv ho zas zacne pouzivat.
Dosledok je inak taky, ze ak mate nejake data s kratkou hlbkou (napr. 3 dni) a spoliehate sa na to, ze su v trezore, tak pocas upratovania mate k dispozicii posledne 3 dni (z archivu), kedze trezor za posledny mesiac nie je k dispozicii a az starsie su… => nie je zdrave sa spoliehat na taketo citanie z trezoru.
Inak trezory by mali sluzit na obcasne citanie, odporucam natiahnut hlbky archivacie tak, aby bolo aspon 90% potrebnych dat v archive.

Dobry den. Problem sme vyriesili na zaklade dodaneho scriptu.
Dakujeme.