Namestitev 1c in postgres v sistemu Windows. Namestite PostgreSQL. Povezovanje zunanjega vira podatkov

Ta članek ne trdi, da je popolna predstavitev vseh možnosti konfiguracije PostgreSQL in v primerjalnem testiranju ne pokrivam vseh načinov delovanja baze podatkov. Zainteresiranim svetujem, da knjigo preučijo na povezavi

Uvod

Veliko sem delal s PostgreSQL in mislim, da je odličen DBMS. Imam večgigabajtno delujočo bazo podatkov (ne 1C), ki takoj obdela ogromne količine podatkov. PostgreSQL odlično izkorišča indekse, dobro se spopada z vzporednimi delovnimi obremenitvami, funkcionalnost shranjenih procedur je odlična, na voljo so dobra skrbniška in zmogljivostna orodja že pripravljena, skupnost pa je ustvarila uporabne pripomočke. Vendar sem bil presenečen, ko sem izvedel, da ima veliko skrbnikov 1C slabo mnenje o PostgreSQL, da je počasen in komaj prekaša datotečno različico baze podatkov, in samo MSSQL lahko reši situacijo.

Po raziskovanju vprašanja sem našel veliko člankov o namestitvi PostgreSQL korak za korakom za telebane, tako v Linuxu kot v sistemu Windows. Toda velika večina člankov opisuje namestitev, dokler ni nameščena - ustvarimo bazo podatkov, in se sploh ne dotika vprašanja konfiguracije. V preostalih je konfiguracija omenjena le na ravni »določite takšne vrednosti«, brez skoraj nobene razlage, zakaj.

In če je pristop »namestitve z enim gumbom« uporaben za MSSQL in številne izdelke za Windows na splošno, potem na žalost ne velja za PostgreSQL. Privzete nastavitve močno omejujejo njegovo porabo pomnilnika, tako da ga lahko namestite tudi na kalkulator in ne bo motil delovanja ostale programske opreme. PostgreSQL mora biti konfiguriran za določen sistem in šele takrat se lahko pokaže najbolje. V posebej hudih primerih lahko prilagodite nastavitve PostgreSQL, baze podatkov in datotečni sistem drug drugega, vendar to v večji meri velja za sisteme Linux, kjer je več možnosti, da vse prilagodite.

Opozoriti je treba, da za 1C sklop PostgreSQL razvijalcev DBMS ni primeren, sestavljen je samo iz zakrpanih izvornih kod 1C. Pripravljene kompatibilne sklope ponujata 1C (prek ITS diskov in računa za tiste z naročnino na podporo) in EterSoft

Testiranje je bilo opravljeno v okolje Windows, vendar vsa priporočila za konfiguracijo niso specifična za platformo in veljajo za kateri koli OS.

Testiranje in primerjava

Pri testiranju se nisem lotil izvajanja testov v vseh načinih delovanja in scenarijih, le grobo preverjanje uspešne konfiguracije.

Za testiranje sem uporabil naslednjo konfiguracijo:
Gostiteljski stroj: Win7, Core i5-760 2,8 MHz, 4 jedra, 12 GB RAM, VMWare 10
Virtualno: Win7 x64, 2 jedri, 4 GB RAM, ločen fizični HDD za gostovanje baze podatkov (ne SSD)
MSSQL Express 2014
PostgreSQL EtherSoft 9.2.1
1C 8.3.5 1383

Uporabljena je bila baza podatkov, dt-upload 780MB.
Po obnovitvi baze podatkov:
velikost datoteke 1CD v datotečni različici - 10GB,
Velikost baze podatkov PostgreSQL - 8GB,
Velikost baze podatkov MSSQL je 6,7 GB.

Za test sem uporabil zahtevo po vzorcu pogodbe nasprotnih strank (21k) z izborom dodatnih podrobnosti iz različnih registrov, za vsako pogodbo je bil dejansko narejen vzorec posebej iz registrov. Vzel sem konfiguracijo, ki je bila pri roki - močno predelano na osnovi Računovodstva 3.0.

Med testiranjem sem večkrat izvedel zahtevo z enim in dvema odjemalcema, dokler niso bili doseženi stabilni rezultati. Prve vožnje sem ignoriral.

Testiranje z eno stranko:

Vzorčenje na gostitelju iz različice datoteke z bazo podatkov na SSD - 31c
Izbira med različico datoteke v navidezni stroj(Z trdi disk) - 46s
Vzorčenje iz baze podatkov MSSQL - prvi prehod - 25 s ali 9 s (očitno odvisno od ustreznosti predpomnilnika DBMS) (poraba pomnilnika s procesom DBMS je bila približno 1,3 GB)
Vzorčenje iz PostgreSQL s privzetimi nastavitvami - 43 s (poraba pomnilnika ni presegla 80 MB na povezavo)
Vzorčenje iz optimiziranega PostgreSQL - 21 s (poraba pomnilnika je bila 120 MB na povezavo)

Testiranje z dvema strankama:

Vzorčenje na gostitelju iz različice datoteke z bazo podatkov na SSD - 34s vsak
Vzorčenje iz datotečne različice v virtualnem stroju (s trdega diska) - 56s vsak
Vzorčenje iz baze podatkov MSSQL - 50s ali 20s (očitno odvisno od ustreznosti predpomnilnika DBMS)
Vzorčenje iz PostgreSQL s privzetimi nastavitvami - po 60 s
Vzorčenje iz optimiziranega PostgreSQL - po 40 s

Opombe o testiranju:

  1. Po dodajanju tretjega jedra sta različici PostgreSQL in MSSQL začeli delovati v testu »dva odjemalca« skoraj z zmogljivostjo testa »enega odjemalca«, tj. uspešno vzporeden. Kaj jim je preprečilo vzporedno delo na dveh jedrih, mi je ostalo skrivnost.
  2. MSSQL je naenkrat zasedel veliko pomnilnika, PostgreSQL pa ga je v vseh načinih zahteval bistveno manj in sprostil skoraj vsega takoj po zaključku poizvedbe.
  3. MSSQL deluje kot en sam proces. PostgreSQL zažene ločen proces na povezavo + storitvene procese. To celo 32-bitni različici omogoča učinkovito uporabo pomnilnika pri obdelavi zahtev več odjemalcev.
  4. Povečanje pomnilnika za PostgreSQL v nastavitvah nad spodaj prikazanimi vrednostmi ni povzročilo opaznega povečanja zmogljivosti.
  5. Prvi testi so v vseh primerih trajali dlje kot pri naslednjih meritvah, posebnih meritev nisem izvajal, MSSQL pa se je subjektivno začel hitreje.

Konfiguriranje PostgreSQL

Obstaja odlična knjiga v ruščini o konfiguraciji in optimizaciji PostgreSQL: smiselno je, da vsak ljubitelj slonov doda to povezavo med zaznamke. Knjiga opisuje številne tehnike za optimizacijo DBMS, ustvarjanje sistemov, odpornih na napake, in porazdeljenih sistemov. Zdaj pa si bomo ogledali nekaj, kar bo koristno vsem - konfiguriranje uporabe pomnilnika. PostgreSQL ne bo porabil več pomnilnika, kot je dovoljeno z nastavitvami, in s privzetimi nastavitvami PostgreSQL uporablja najmanj pomnilnika. Hkrati ne smete določiti več pomnilnika, kot je na voljo za uporabo - sistem bo začel uporabljati izmenjalno datoteko z vsemi posledičnimi hudimi posledicami za delovanje strežnika. Na disku ITS je podanih nekaj nasvetov za nastavitev PostgreSQL.

V sistemu Windows se konfiguracijske datoteke PostgreSQL nahajajo v namestitvenem imeniku v imeniku podatkov:

  • postgresql.conf- glavna datoteka z nastavitvami DBMS
  • pg_hba.conf- datoteka z nastavitvami dostopa za stranke. Predvsem tukaj lahko določite, kateri uporabniki s katerih naslovov IP se lahko povežejo z določenimi zbirkami podatkov in ali je potrebno preveriti uporabniško geslo in na kakšen način.
  • pg_ident.conf- datoteka s pretvorbo uporabniških imen iz sistemskih v interna (večina uporabnikov je verjetno ne bo potrebovala)

Datoteke so besedilne, urejate jih lahko z beležnico. Vrstice, ki se začnejo z # štejejo za komentarje in se ne upoštevajo.

Parametri, povezani s kapaciteto pomnilnika, se lahko dopolnijo s priponami kB, MB, GB - kilobajti, megabajti, gigabajti, na primer 128 MB. Parametri, ki opisujejo časovne intervale, se lahko dopolnijo s priponami ms, s, min, h, d - milisekunde, sekunde, minute, ure, dnevi, na primer 5min

Če ste pozabili geslo za Postgress, ni problema, lahko ga vpišete pg_hba.conf vrstica:

Gosti vse vse 127.0.0.1/32 zaupanja

In se poveže s katerim koli uporabnikom (npr. postgres) v DBMS na lokalnem računalniku na 127.0.0.1 brez preverjanja gesla.

Optimizacija uporaba pomnilnika

Nastavitve porabe pomnilnika se nahajajo v postgresql.conf

Optimalne vrednosti parametrov so odvisne od količine prostega pomnilnik z naključnim dostopom, velikost baze podatkov in posameznih elementov baze (tabele in indeksi), kompleksnost poizvedb (načeloma je treba domnevati, da bodo poizvedbe precej zapletene – več povezav v poizvedbah je tipičen scenarij) in število istočasno aktivnih strank. Mimogrede, PostgreSQL shranjuje tabele baze podatkov in indekse ločene datoteke (<каталог установки PG>\podatki\baza\<идентификатор БД>\), in velikosti predmetov je mogoče oceniti. Uporabite lahko tudi priloženi pripomoček pgAdmin, da se povežete z bazo podatkov, razširite »Sheme« - »javno« in ustvarite statistično poročilo za element »Tabele«.

Nato bom podal približne vrednosti, od katerih lahko začnete nastavljati. Po začetna nastavitev Priporočljivo je, da strežnik zaženete v načinih delovanja in spremljate porabo pomnilnika. Glede na dobljene rezultate bo morda treba prilagoditi vrednosti parametrov.

Pri nastavitvi strežnika za testiranje sem se zanašal na naslednje izračune:
Samo 4 GB RAM-a. Potrošniki - Windows OS, strežnik 1C, PostgreSQL in predpomnilnik sistemskega diska. Predvideval sem, da je mogoče DBMS dodeliti do 2,5 GB RAM-a

Vrednosti lahko določite s priponami kB, MB, GB (vrednosti v kilobajtih, megabajtih ali gigabajtih). Po spremembi vrednosti morate znova zagnati storitev PostgreSQL.

shared_buffers – Medpomnilnik strežnika v skupni rabi

Velikost predpomnilnika za branje in pisanje PostgreSQL, ki si ga delijo vse povezave. Če podatkov ni v predpomnilniku, se preberejo z diska (morda jih predpomni OS)

Če velikost vmesnega pomnilnika ne zadošča za shranjevanje pogosto uporabljenih delovnih podatkov, se bodo nenehno zapisovali in brali iz predpomnilnika OS ali z diska, kar bo izjemno negativno vplivalo na zmogljivost.

Vendar to ni ves pomnilnik, ki je potreben za delovanje, ne smete navesti preveč velik pomen, sicer ne bo ostalo pomnilnika tako za dejansko izvajanje zahtev odjemalcev (in več kot jih je, večja je poraba pomnilnika) kot za OS in druge aplikacije, na primer strežniški proces 1C. Strežnik se prav tako zanaša na predpomnilnik operacijskega sistema in poskuša v svojem medpomnilniku ohraniti tisto, kar je najverjetneje predpomnil sistem.

Uporabljeni test

skupni_medpomnilniki = 512 MB

delovni_mem- pomnilnik za sortiranje, združevanje podatkov itd.

Dodeljeno za vsako zahtevo, morda večkrat za kompleksne zahteve. Če ni dovolj pomnilnika, bo PostgreSQL uporabil začasne datoteke. Če je vrednost prevelika, je lahko RAM preobremenjen in OS bo začel uporabljati izmenjalno datoteko z ustreznim padcem zmogljivosti.

Obstaja priporočilo, da pri izračunu vzamete količino razpoložljivega pomnilnika minus deljeni_medpomnilniki, in delite s številom istočasno izvedenih zahtev. V primeru zapletenih poizvedb je treba delitelj povečati, tj. zmanjšati rezultat. Za obravnavani primer na podlagi 5 aktivnih uporabnikov (2,5 GB-0,5 GB (shared_buffers))/5=400 MB. Če DBMS meni, da so poizvedbe precej zapletene ali če se pojavijo dodatni uporabniki, bo treba vrednost zmanjšati.

Za preproste poizvedbe zadostujejo majhne vrednosti - do nekaj megabajtov, za zapletene poizvedbe (in to je tipičen scenarij za 1C) bo potrebno več. Priporočilo - za pomnilnik 1-4GB lahko uporabite vrednosti 32-128MB. Uporabljeno v testu

work_mem = 128 MB

vzdrževanje_delo_mem- pomnilnik za ukaze za zbiranje smeti, statistiko, ustvarjanje indeksa.

Priporočljivo je, da vrednost nastavite na 50-75 % velikosti največje tabele ali indeksa, vendar tako, da je dovolj pomnilnika za delovanje sistema in aplikacij. Priporočljivo je, da nastavite vrednosti, večje od work_mem. Uporabljeno v testu
vzdrževalno_delo_mem = 192 MB

temp_buffers- medpomnilnik za začasne objekte, predvsem za začasne tabele.

Namestite lahko približno 16 MB. Uporabljeno v testu
temp_buffers = 32 MB

efektivna_velikost_predpomnilnika- približna velikost diskovnega predpomnilnika datotečnega sistema.

Optimizator uporablja to vrednost pri izdelavi načrta poizvedbe za oceno verjetnosti, da bodo podatki najdeni v predpomnilniku (s hitrim naključnim dostopom) ali na počasnem disku. V sistemu Windows si lahko trenutno količino pomnilnika, dodeljenega predpomnilniku, ogledate v upravitelju opravil.

Avtovakuum - "odvoz smeti"

PostgreSQL, kot tipičen predstavnik "verzioniranih" DBMS (v nasprotju z blokiranimi), ne blokira neodvisno tabel in zapisov pri branju transakcij pri spreminjanju podatkov (v primeru 1C to počne sam strežnik 1C). Namesto tega se ustvari kopija spremenjenega zapisa, ki postane vidna za naslednje transakcije, medtem ko obstoječe še naprej vidijo podatke, ki so bili aktualni na začetku njihove transakcije. Posledično se v tabelah kopičijo zastareli podatki – prejšnje različice spremenjeni zapisi. Da bi DBMS lahko uporabil sproščeni prostor, je potrebno izvesti "pobiranje smeti" - ugotoviti, kateri od zapisov se ne uporabljajo več. To lahko storite eksplicitno z ukazom SQL VAKUUM, ali počakajte, da tabelo obdela samodejni zbiralnik smeti - AVTOVAKUUM. Prav tako je bilo do določene različice zbiranje smeti povezano z zbiranjem statistike (planer uporablja podatke o številu zapisov v tabelah in porazdelitvi vrednosti indeksiranih polj za izdelavo optimalnega načrta poizvedbe). Po eni strani je treba zbiranje smeti izvesti tako, da tabele ne rastejo in učinkovito uporabljajo prostor na disku. Po drugi strani pa nenadno začeto zbiranje smeti dodatno obremeni disk in tabele, kar povzroči podaljšanje časa izvajanja poizvedbe. Podoben učinek ustvari samodejno zbiranje statističnih podatkov (očitno ga je mogoče zagnati z ukazom ANALIZIRAJ ali skupaj z odvozom smeti ANALIZA PODTLAKA). In čeprav PostgreSQL te mehanizme izboljšuje od različice do različice, da jih zmanjša Negativni vpliv na delovanje (na primer, v prejšnjih različicah je zbiranje smeti popolnoma blokiralo dostop do tabele, od različice 9.0 delo VAKUUM pospešeno), tukaj je treba nekaj konfigurirati.

Samodejni vakuum lahko popolnoma onemogočite z naslednjim parametrom:

avtovakuum = izklopljen

Poleg tega je za delovanje Autovacuum potreben parameter track_counts = on, sicer ne bo deloval.

Privzeto sta obe možnosti omogočeni. Pravzaprav avtovakuuma ni mogoče popolnoma onemogočiti - tudi če je avtovakuum = izklopljen, se včasih (po velikem številu transakcij) začne avtovakuum.

komentar: VAKUUM običajno ne zmanjša velikosti datoteke tabele, samo označi prosta področja, ki so na voljo za ponovno uporabo. Če želite fizično sprostiti odvečni prostor in minimizirati zaseden prostor na disku, boste potrebovali ukaz VAKUUM POLN. Ta možnost blokira dostop do tabele med izvajanjem in običajno ni potrebna. Več informacij o uporabi ukaza VACUUM najdete v dokumentaciji (v angleščini).

Če Autovacuum ni popolnoma onemogočen, lahko konfigurirate njegov vpliv na izvajanje poizvedbe z naslednjimi parametri:

avtovakuum_max_delavci- največje število vzporedno tekočih procesov čiščenja.

autovacuum_naptime - minimalni interval, pod katerim se avtovakuum ne bo začel. Privzeto je 1 minuta. Lahko ga povečate, če pa se podatki pogosto spreminjajo, se bo analiza izvajala manj pogosto.

avtovacuum_vacuum_threshold, - število spremenjenih ali izbrisanih zapisov v tabeli, potrebnih za sprožitev postopka zbiranja smeti VAKUUM ali zbiranje statistike ANALIZIRAJ. Privzeto je 50.

faktor_razsežnosti_vakuuma_vakuuma , faktor_razsežnosti_analize_avtovakuuma - koeficient velikosti tabele v dodanih zapisih avtovakuumski_prag_vakuuma in prag_analize_avtovakuuma oz. Privzete vrednosti so 0,2 (tj. 20 % števila zapisov) oziroma 0,1 (10 %).

Oglejmo si primer s tabelo z 10.000 zapisi. Nato se s privzetimi nastavitvami po 50+10000*0,1=1050 spremenjenih ali izbrisanih zapisih začne zbiranje statistike ANALIZIRAJ, po letu 2050 pa spremembe - odvoz smeti VAKUUM.

Če povečate threshold in scale_factor, se bodo procesi vzdrževanja izvajali manj pogosto, vendar se lahko majhne tabele znatno povečajo. Če je zbirka podatkov sestavljena predvsem iz majhnih tabel, je lahko splošno povečanje porabe prostora na disku precejšnje, zato lahko povečate te vrednosti, vendar pametno.

Zato je morda smiselno povečati interval autovacuum_naptime ter rahlo povečati prag in scale_factor. V naloženih bazah podatkov je morda alternativa občutnemu zvišanju scale_factor (vrednost 1 bo omogočila, da se tabele dvakrat »napihnejo«) in nastavitev dnevnega izvajanja za razporejevalnik ANALIZA PODTLAKA v obdobjih minimalne obremenitve baze podatkov.

default_statistics_target - dodeli količino statistike, ki jo zbere ukaz ANALIZIRAJ. Privzeta vrednost je 100. Večje vrednosti podaljšajo čas izvajanja ukaza ANALIZIRAJ, vendar razporejevalniku omogočajo, da zgradi učinkovitejše načrte poizvedb. Obstajajo priporočila za povečanje na 300.

Delovanje je mogoče nadzorovati AVTOVAKUUM, zaradi česar je daljši, a manj obremenjujoč sistem.

vacuum_cost_page_hit- velikost "fine" za obdelavo bloka, ki se nahaja v shared_buffers. Povezano s potrebo po blokiranju dostopa do medpomnilnika. Privzeta vrednost 1

vacuum_cost_page_miss - velikost "globe" za obdelavo bloka na disku. Povezano z blokiranjem medpomnilnika, iskanjem podatkov v medpomnilniku, branjem podatkov z diska. Privzeta vrednost 10

vacuum_cost_page_dirty- velikost "fine" za modifikacijo bloka. Povezano s potrebo po ponastavitvi spremenjenih podatkov na disk. Privzeta vrednost 20

omejitev_stroška_vakuuma- največja količina "glob", po kateri se lahko postopek sestavljanja "zamrzne" za čas trajanja vacuum_cost_delay. Privzeto 200

vakuum_strošek_zakasnitve- čas za "zamrznitev" postopka zbiranja smeti, ko je dosežena vacuum_cost_limit. Privzeta vrednost 0ms

avtovakuum_vakuum_strošek_zakasnitev- čas za "zamrznitev" postopka zbiranja smeti za avtovakuum. Privzeto je 20 ms. Če je nastavljeno na -1, bo uporabljena vrednost vacuum_cost_delay

avtovakuum_vakuum_cena_omejitve- največja velikost "globe" za avtovakuum. Privzeta vrednost -1 - uporabljena je vrednost vacuum_cost_limit

Prijavljena uporaba vacuum_cost_page_hit = 6, meja_stroška_vakuuma = 100, avtovacuum_vacuum_cost_delay = 200ms zmanjša učinek AVTOVAKUUMA do 80%, vendar potroji čas njegovega izvajanja.

Nastavitev snemanja diska

Ko je transakcija končana, PostgreSQL najprej zapiše podatke v poseben dnevnik transakcij WAL (Write-ahead log) in nato v bazo podatkov, potem ko so podatki dnevnika zajamčeno zapisani na disk. Privzeti mehanizem je fsync, ko PostgreSQL na silo izbriše podatke (dnevnik) iz diskovnega predpomnilnika OS na disk in šele po uspešnem pisanju (dnevnik) je odjemalec obveščen, da je bila transakcija uspešno zaključena. Uporaba dnevnika transakcij vam omogoča dokončanje transakcije ali obnovitev baze podatkov, če med zapisovanjem podatkov pride do napake.

V obremenjenih sistemih z velikimi količinami zapisovanja je morda smiselno dnevnik transakcij premakniti na ločen fizični disk (vendar ne na drugo particijo istega diska!). Če želite to narediti, morate ustaviti DBMS, premakniti imenik pg_xlog na drugo lokacijo in ustvariti simbolično povezavo na stari lokaciji, na primer z uporabo pripomočka junction. Far Manager (Alt-F6) lahko ustvari tudi povezave. V tem primeru se morate prepričati, da ima nova lokacija pravice dostopa za uporabnika, ki izvaja PostgreSQL (običajno postgres).

Če obstaja veliko število operacij spreminjanja podatkov, boste morda morali povečati vrednost checkpoint_segments, ki nadzira količino podatkov, ki lahko čakajo na prenos iz dnevnika v samo bazo podatkov. Privzeta vrednost je 3. Upoštevati je treba, da je za dnevnik dodeljen prostor, izračunan po formuli (checkpoint_segments * 2 + 1) * 16 MB, kar bo pri vrednosti 32 že zahtevalo več kot 1 GB diska. prostora.

PostgreSQL splakne podatke iz predpomnilnika datotek OS na disk, ko je vsaka transakcija pisanja končana. Po eni strani to zagotavlja, da so podatki na disku vedno posodobljeni, po drugi strani pa se z velikim številom transakcij zmogljivost zmanjša. Popolnoma onemogoči fsync možno z navedbo

fsync=izklopljeno
full_page_writes = izklopljeno

To je mogoče le, če 100% zaupate opremi in UPS-u (vir brezprekinitveno napajanje). V nasprotnem primeru obstaja tveganje, da v primeru zrušitve sistema pride do uničenja baze podatkov. In v vsakem primeru tudi krmilnik RAID z baterijo za napajanje pomnilnika nezapisanih podatkov ne bi škodil.

Dokončna alternativa bi lahko bila uporaba parametra

synchronous_commit = izklopljeno

V tem primeru lahko po uspešnem odgovoru za dokončanje transakcije traja nekaj časa, preden se transakcija varno zapiše na disk. V primeru nenadne zaustavitve baza podatkov ne bo uničena, lahko pa se izgubijo podatki iz zadnjih transakcij.

Če funkcije fsync ne onemogočite popolnoma, lahko v parametru določite način sinhronizacije. Članek z diska ITS se nanaša na pripomoček pg_test_fsync, vendar ga v moji gradnji PostgreSQL ni bilo mogoče najti. Po mnenju 1C se je v njihovem primeru v sistemu Windows metoda izkazala za optimalno open_datasync(očitno je to metoda, ki se uporablja privzeto).

Če se uporablja veliko majhnih transakcij pisanja (v primeru 1C je to lahko množična posodobitev imenika zunaj transakcije), kombinacija parametrov commit_delay (čas zakasnitve zaključka transakcije v mikrosekundah, privzeto 0) in commit_siblings (privzeto 5) lahko pomagam. Ko so možnosti omogočene, lahko dokončanje transakcije zakasni commit_delay, če ta trenutek Izvedene so vsaj transakcije commit_siblings. V tem primeru bo rezultat vseh opravljenih transakcij zapisan skupaj za optimizacijo zapisovanja na disk.

Drugi parametri, ki vplivajo na zmogljivost

wal_buffers- količina pomnilnika v shared_buffers za vzdrževanje dnevnikov transakcij. Priporočilo: pri 1–4 GB razpoložljivega pomnilnika uporabite vrednosti 256 KB–1 MB. Dokumentacija navaja, da uporaba vrednosti "-1" samodejno prilagodi vrednost glede na vrednost shared_buffers.

random_page_cost- »strošek« naključnega branja, ki se uporablja pri iskanju podatkov z uporabo indeksov. Privzeto je 4.0. Enota je čas zaporednega dostopa do podatkov. Pri hitrih diskovnih poljih, predvsem SSD, je vrednost smiselno znižati, v tem primeru bo PostgreSQL bolj aktivno uporabljal indekse.

Knjiga na povezavi ima še nekaj drugih parametrov, ki jih je mogoče konfigurirati. Močno priporočamo tudi, da preberete dokumentacijo PostgreSQL o dodeljevanju določenih parametrov.

Priporočljivo je, da spremenite parametre v razdelku QUERY TUNING, zlasti tiste, ki se nanašajo na prepoved razporejevalniku uporabe določenih metod iskanja, le če popolnoma razumete, kaj počnete. Zelo enostavno je optimizirati eno vrsto poizvedbe in uničiti delovanje vseh drugih. Učinkovitost spreminjanja večine parametrov v tem razdelku je odvisna od podatkov v bazi podatkov, poizvedb do teh podatkov (tj. Med drugim uporabljene različice 1C) in različice DBMS.

Zaključek

PostgreSQL je močan DBMS v sposobnih rokah, vendar zahteva skrbno konfiguracijo. Lahko se uporablja v povezavi z 1C in zagotovi dostojno zmogljivost, njegova brezplačna narava pa bo zelo lep bonus.

Kritike in dopolnitve tega članka so dobrodošle.

koristne povezave

http://postgresql.leopard.in.ua/ - spletno mesto knjige " Delo s konfiguracijo in skaliranjem PostgreSQL ", po mojem mnenju najbolj popoln in razumljiv vodnik za konfiguriranje in upravljanje PostgreSQL

http://etersoft.ru/products/postgre - tukaj lahko prenesete 1C-združljivo gradnjo PostgreSQL za Windows ter različne distribucije in različice Linuxa. Za tiste, ki nimate naročnine na ITS ali potrebujete različico za Različica Linuxa, ki ni predstavljen na v8.1c.ru.

http://www.postgresql.org/docs/9.2/static/ - uradna dokumentacija o PostgreSQL (v angleščini)

Članki z ITS diska o nastavitvi PostgreSQL

Zgodovina urejanja članka

  • 29.01.2015 - objavljena začetna različica
  • 31.01.2015 - članek je dopolnjen z rubriko AVTOVAKUUM, dodana je povezava do originalne dokumentacije.

V prihodnje nameravam preizkusiti delovanje DBMS v načinu dodajanja in spreminjanja podatkov.

Vgradili bomo sklop podjetja Postgres Professional. Na strani z različico za 1C:Enterprise bomo našli informacije o namestitvi najnovejše različice PostgreSQL na CentOS 7.

Povežimo repozitorije in namestimo PostgreSQL 9.6:

Sudo rpm -ivh http://1c.postgrespro.ru/keys/postgrespro-1c-centos96.noarch.rpm sudo yum makecache sudo yum namestitev postgresql-pro-1c-9.6

Osnovna nastavitev PostgreSQL

Inicializiramo podatkovne baze storitev z rusko lokalizacijo:

Su postgres /usr/pgsql-9.6/bin/initdb -D /var/lib/pgsql/9.6/data --locale=ru_RU.UTF-8 izhodna storitev postgresql-9.6 initdb

Zaženite storitev PostgreSQL in jo dodajte v zagon:

Systemctl omogoči postgresql-9.6 systemctl zaženi postgresql-9.6 status systemctl postgresql-9.6

Za uporabnika postgres nastavimo geslo, da se lahko povežemo s strežnikom na daljavo:

Su - postgres psql SPREMENI UPORABNIKA postgres S ŠIFRIRANIM GESLOM "vaše geslo"; \q izhod

Mcedit /var/lib/pgsql/9.6/data/pg_hba.conf

v datoteki, ki se odpre, odkomentirajte in spremenite vrstice:

gosti vse vse 127.0.0.1/32 ident na gosti vse vse 127.0.0.1/32 md5

gosti vse vse 0.0.0.0/0 ident na gosti vse vse 0.0.0.0/0 md5

Optimizacija nastavitev PostgreSQL (postgresql.conf) za 1C:Enterprise

Tukaj bodo nastavitve za PostgreSQL, ki se izvaja v virtualnem stroju ESXi 6.5.

Viri, dodeljeni za VM:

procesor - 8 vCPU;

pomnilnik - 48 GB;

disk za OS - 50 GB na LUN strojni opremi RAID1 iz SAS HDD;

disk za podatkovno bazo - 170 GB na programskem RAID1 iz SSD

disk za dnevnike - 100 GB na programskem RAID1 iz SSD

Če želite urediti nastavitve, zaženite ukaz:

Mcedit /var/lib/pgsql/9.6/data/postgresql.conf

Komentirani parametri, ki jih bomo spremenili, morajo biti aktivirani.

procesor

avtovakuum_max_delavci = 4

autovacuum_max_workers = NCores/4..2 vendar ne manj kot 4

Število avtovakuumskih procesov. Splošno pravilo je, da več ko je zahtev za pisanje, več procesov. V bazi podatkov samo za branje je dovolj en proces.

ssl=izklopljeno

Izklopite šifriranje. Za varne podatkovne centre je šifriranje nesmiselno, vodi pa do povečane obremenitve procesorja

Spomin

skupni_medpomnilniki = 12 GB

deljeni_medpomnilniki = RAM/4

Količina pomnilnika, ki jo dodeli PgSQL za predpomnilnik strani v skupni rabi. Ta pomnilnik si delijo vsi procesi PgSQL. operacijski sistem Podatke predpomni sam, zato ni treba dodeliti vsega razpoložljivega RAM-a za predpomnilnik.

temp_buffers = 256 MB

Največje število strani za začasne tabele. Tisti. to je zgornja meja velikosti začasnih tabel v vsaki seji.

work_mem = 64 MB

work_mem = RAM/32..64 ali 32MB..128MB

Omejitev pomnilnika za obdelavo ene zahteve. Ta spomin je individualen za vsako sejo. Teoretično je največji zahtevani pomnilnik enak max_connections * work_mem, v praksi se to ne zgodi, ker večina sej skoraj vedno čaka. To svetovalno vrednost uporablja optimizator: poskuša predvideti velikost pomnilnika, potrebnega za poizvedbo, in če je ta vrednost večja od work_mem, sporoči izvajalcu, naj takoj ustvari začasno tabelo. work_mem ni omejitev v polnem pomenu: optimizator lahko zgreši in zahteva bo zavzela več pomnilnika, morda večkrat več. To vrednost je mogoče zmanjšati s spremljanjem števila ustvarjenih začasnih datotek:

vzdrževalna_dela_mem = 2 GB

vzdrževanje_delovni_mem = RAM/16..32 ali delovni_mem * 4 ali 256MB..4GB

Omejitev pomnilnika za vzdrževalna opravila, kot je zbiranje statističnih podatkov (ANALYZE), zbiranje smeti (VACUUM), ustvarjanje indeksov (CREATE INDEX) in dodajanje tujih ključev. Velikost pomnilnika, dodeljenega za te operacije, mora biti primerljiva z fizična velikost največji indeks na disku.

efektivna_velikost_predpomnilnika = 36 GB

efektivna_velikost_predpomnilnika = RAM - skupni_medpomnilniki

Ocena velikosti predpomnilnika datotečnega sistema. Povečanje parametra poveča nagnjenost sistema k izbiri načrtov IndexScan. In to je dobro.

Diski

efektivna_io_sočasnost = 5

Ocena sočasnih zahtev do diskovnega sistema, ki jih lahko servisira naenkrat. Za en disk = 1, za RAID - 2 ali več.

random_page_cost = 1,3

random_page_cost = 1,5-2,0 za RAID, 1,1-1,3 za SSD

Stroški branja naključne strani (privzeto 4). Manjši kot je čas iskanja diskovnega sistema, manjši (vendar > 1,0) mora biti ta parameter. Prevelika vrednost parametra poveča nagnjenost PgSQL k izbiri načrtov, ki pregledujejo celotno tabelo (PgSQL meni, da je cenejše branje celotne tabele zaporedno kot naključno branje indeksa). In to je slabo.

avtovakuum=vklopljen

Vklop avtovakuma.

avtovacuum_naptime = 20s

Čas mirovanja procesa avtovakuumiranja. Če je vrednost prevelika, tabele ne bodo imele časa za vakuumiranje in posledično se bo povečala napihnjenost ter velikost tabel in indeksov. Majhna vrednost bo povzročila nepotrebno segrevanje.

bgwriter_delay = 20ms

Čas mirovanja med cikli zapisovanja na disk v procesu pisanja v ozadju. Ta proces je odgovoren za sinhronizacijo strani, ki se nahajajo v shared_buffers, z diskom. Prevelika vrednost za ta parameter bo povečala obremenitev procesa kontrolne točke in procesov, ki strežejo seje (backend). Majhna vrednost bo povzročila, da bo eno od jeder polno naloženo.

bgwriter_lru_multiplier = 4,0

bgwriter_lru_maxpages = 400

Možnosti, ki nadzirajo intenzivnost snemanja v procesu snemanja v ozadju. V enem ciklu bgwriter ne zapiše več kot je bilo napisano v zadnjem ciklu, pomnoženo z bgwriter_lru_multiplier, vendar ne več kot bgwriter_lru_maxpages.

synchronous_commit = izklopljeno

Onemogoči sinhronizacijo diska v času potrditve. Ustvari tveganje izgube zadnjih nekaj transakcij (v 0,5-1 sekundah), vendar zagotavlja celovitost baze podatkov; v verigi potrditve ni vrzeli. Vendar bistveno poveča produktivnost.

wal_keep_segments = 256

wal_keep_segments = 32..256

Največje število segmentov WAL med kontrolnimi točkami. Prepogoste kontrolne točke vodijo do znatne pisalne obremenitve diskovnega podsistema. Vsak segment je velik 16 MB

wal_buffers = 16 MB

Količina skupnega pomnilnika, ki bo uporabljen za medpomnjenje podatkov WAL, ki še niso zapisani na disk. Privzeta vrednost -1 določa velikost, ki je enaka 1/32 (približno 3 %) od , vendar ne manj kot 64 KB in ne več kot velikost posameznega segmenta WAL (običajno 16 MB). To vrednost je mogoče nastaviti ročno, če je samodejno izbrana premajhna ali velika, vendar bo vsako pozitivno število, manjše od 32 KB, obravnavano kot 32 KB. Ta parameter je mogoče nastaviti samo ob zagonu strežnika.

Vsebina vmesnih pomnilnikov WAL se ob vsaki transakciji zapiše na disk, zato zelo velike vrednosti verjetno ne bodo prinesle veliko koristi. Vendar pa lahko vrednost vsaj nekaj megabajtov izboljša zmogljivost pisanja na zasedenem strežniku, ko veliko odjemalcev izvaja transakcije hkrati. Samodejno prilagajanje, ki deluje pri privzeti vrednosti (-1), v večini primerov izbere razumne vrednosti.

default_statistics_target = 1000

Nastavi privzeto ciljno mejo statistike, ki velja za stolpce, za katere ALTER TABLE SET STATISTICS ni podal posameznih omejitev. Višja kot je nastavljena vrednost, dlje traja izvajanje ANALYZE, vendar je lahko kakovost ocen razporejevalnika večja. Privzeta vrednost za ta parameter je 100.

cilj_dokončanja_kontrolne_točke = 0,9

Stopnja "razmazanja" kontrolne točke. Hitrost snemanja med kontrolno točko je prilagojena tako, da je čas kontrolne točke enak času, ki je pretekel od preteklosti, pomnoženemu s ciljem checkpoint_completion_.

min_wal_size = 4G
max_wal_size = 8G

min_wal_size = 512 MB .. 4G
max_wal_size = 2 * najmanj_wal_size

Najmanjša in največja velikost datotek WAL. Podobno kot checkpoint_segments

fsync=on

Če onemogočite možnost, se poveča zmogljivost, vendar obstaja velika nevarnost izgube vseh podatkov, če se napajanje nenadoma izklopi. Pozor: če ima RAID predpomnilnik in je v načinu povratnega pisanja, preverite prisotnost in delovanje predpomnilniške baterije krmilnika RAID! V nasprotnem primeru se lahko podatki, zapisani v predpomnilnik RAID, izgubijo, ko je napajanje izklopljeno, zato PgSQL ne jamči celovitosti podatkov.

varnost_vrstice = izklopljeno

Onemogočanje nadzora ločljivosti ravni zapisa

enable_nestloop = izklopljeno

Omogoči ali onemogoči načrtovalčevo uporabo načrtov združevanja z ugnezdeno zanko. Ugnezdenih zank ni mogoče popolnoma odstraniti, vendar če to možnost izklopite, razporejevalnik ne bo uporabljal ta metoda, če je mogoče uporabiti druge. Privzeto je ta nastavitev vklopljena.

Ključavnice

max_locks_per_transaction = 256

Največje število zaklepanja indeksov/tabel v eni transakciji

Nastavitve za platformo 1C

standard_conforming_strings = izklopljeno

Dovoli uporabo znaka \ za ubežanje

escape_string_warning = izklopljeno

Ne opozarjaj na uporabo znaka \ za ubežanje

Varnostne nastavitve

Prepričajmo se, da je strežnik PostgreSQL viden samo strežniku 1C: Enterprise, ki je nameščen na istem računalniku.

listen_addresses = 'localhost'

Če je strežnik 1C: Enterprise nameščen na drugem računalniku ali se je treba povezati s strežnikom DBMS z uporabo snap-ina PGAdmin, namesto tega lokalni gostitelj določiti morate naslov te naprave.

Shranjevanje baze podatkov

PostgreSQL, tako kot skoraj vsak DBMS, je ključnega pomena za diskovni podsistem, zato bomo za povečanje zmogljivosti DBMS sistem PostgreSQL, dnevnike in same baze podatkov postavili na različne diske.

Zaustavitev strežnika

Systemctl stop postgresql-9.6

Dnevnike prenašamo na 120GB SSD:

Mv /var/lib/pgsql/9.6/data/pg_xlog /raid120 mv /var/lib/pgsql/9.6/data/pg_clog /raid120 mv /var/lib/pgsql/9.6/data/pg_log /raid120

Ln -s /raid120/pg_xlog /var/lib/pgsql/9.6/data/pg_xlog ln -s /raid120/pg_clog /var/lib/pgsql/9.6/data/pg_clog ln -s /raid120/pg_log /var/lib/ pgsql/9.6/data/pg_log

Prenesli bomo tudi imenik z bazami podatkov:

Mv /var/lib/pgsql/9.6/data/base /raid200

Ln -s /raid200/base /var/lib/pgsql/9.6/data/base

Zaženimo strežnik in preverimo njegov status

Systemctl start postgresql-9.6 status systemctl postgresql-9.6

Primer uporabe kot strežnik baze podatkov PostgreSQL na platforma Windows ni zelo priljubljen, vendar se običajno pojavi, ko morate nekako prihraniti denar za izdelke iz MS. Obstajajo tudi specializirane aplikacije, ki najbolje delujejo s PostgreSQL. Za 1c je spremenjena zgradba PostgreSQL, ki, kot zagotavljajo razvijalci, daje raven zmogljivosti in tolerance napak, primerljivo z MSSQL. Ali je res tako, preverimo v praksi :)

1. Namestite PostgreSQL

Prenesi zadnji build PostgreSQL 64-bit 9.1.2-1.1C s spletne strani 1c, razpakiraj arhiv, poženi paket msi, tisti brez int nima velike datoteke.

Kliknite Start.
Možnosti namestitve pustite privzete.

Nastavite geslo za uporabnika postgres iz katerega se začne storitev . Kliknite Naprej. Če PostgreSQL nameščate prvič, vas bo čarovnik pozval, da ustvarite uporabnika postgres.

Na stopnji inicializacije baze podatkov izberite kodiranje UTF8. Nastavite prijavo in geslo za internega uporabnika postgres. Pozor! Uporabniško geslo storitve PostgreSQL in uporabniško geslo interne baze podatkov PostgreSQL ne smeta biti enaka. Geslo mora biti dolgo vsaj štiri znake. Če nameravate zagnati strežnik 1C in PostgreSQL na različnih računalnikih, morate potrditi polje »Podpri povezave s katerega koli IP-ja, ne samo lokalnega gostitelja«. Kliknite Naprej in znova Naprej. :)

Dvakrat kliknite Naprej in počakajte, da se namestitev konča.

Nato pojdite na Start\Vsi programi\PostgreSQL 9.1.2-1.1C(x64). Zaženite skrbniški pripomoček pgAdmin III. Poskusimo se povezati z bazo podatkov. Vnesite geslo, ki ste ga določili med namestitvijo.
Dobimo naslednjo napako: Napaka pri povezovanju s strežnikom: USODNO: preverjanje pristnosti gesla ni uspelo za uporabnika »postgres«.

Precej nepričakovano, glede na to, da je bilo geslo pravilno vtipkano. Odločil sem se poigrati s pg_hba.conf, vendar je na prvi pogled tam vse v redu.

# VRSTA BAZE PODATKOV NASLOV UPORABNIKA METODA # lokalne povezave IPv4: gosti vse postgres::1/128 md5 gosti vse postgres 127.0.0.1/32 md5 gosti vse postgres 192.168.1.0/24 md5

Odločil sem se spremeniti način avtorizacije iz md5 v zaupanje. Znova zaženem storitev in se znova poskusim povezati z bazo podatkov. Tokrat sem prejel to sporočilo.
Dejansko je na spletnem mestu pgAdmin na voljo več kot eden nova različica. Po tem je povezava z bazo uspešna!!?!! Spomnim se, da prej md5 ni povzročal takšnih težav, očitno je ta napaka res povezana z stara različica pgAdmin.
Zdaj lahko ustvarimo bazo podatkov za potrebe 1C ali pa to storimo s samim 1C :)

2. Namestitev 1C podjetje 8.2.

Za namestitev upoštevamo naslednje komponente: 1C:Enterprise, 1C:Enterprise Server, razširitveni moduli spletnega strežnika, administracija strežnika 1C:Enterprise.
V fazi namestitve »Namesti 1C Enterprise kot storitev« nastavimo geslo za uporabnika USR1C82.
Kliknite naprej in spremljajte potek namestitve :) Uporabniku USR1CV82 Med namestitvijo je treba dodeliti naslednje pravice:

Prijava kot storitev (Prijava kot storitev), Prijavite se kot paketno opravilo (Prijavite se kot paketno opravilo). Ogledate si ga lahko na Politika lokalnega računalnika\Konfiguracija računalnika\Nastavitve Windows\Varnostne nastavitve\Lokalna pravila\Dodelitev uporabniških pravic.

Pojdimo k opremi Administracija strežnikov 1C Enterprise, Vidimo, da se je gruča dvignila in visi na vratih 1541. Naš strežnik je prisoten tudi na zavihku “Delujoči strežniki”. Zdaj lahko bazo podatkov dodate na strežnik 1C. Če želite to narediti, pojdite na zavihek » Informacijske baze"Desni klik in izberite Novo - Informacijska baza. Nastavite potrebne parametre za povezavo s strežnikom PostgreSQL. Kliknite OK. Zaženimo 1C: Enterprise. Odločimo se za dodajanje obstoječe informacijske baze na strežnik.
Nato nastavite parametre povezave. Kliknite »Naprej« in na koncu »Dokončaj«.
Operacijo ustvarjanja baze podatkov lahko izvedete neposredno iz 1C: Enterprise. Če želite to narediti, ob zagonu izberite »Ustvari novo informacijsko bazo».

Za povezavo odjemalcev 1C s strežnikom od zunaj in upravljanje strežnika baze podatkov na požarnem zidu morajo biti odprta naslednja vrata:

Agent strežnika ( ragent) - tcp:1540 Glavni upravitelj gruče ( rmngr) - tcp:1541 Razpon omrežnih vrat za dinamično porazdelitev delovnih procesov - tcp:1560-1591, tcp:5432 - Postgresql. Ustvarimo pravilo prek standardnega vmesnika ali z ukazom:

netsh advfirewall firewall add rule name="1Cv8-Server" dir=in action=allow protocol=TCP localport=1540,1541,5432,1560-1590 enable=yes profile=ANY remoteip=ANY interfacetype=LAN

Zdaj lahko preprosto zaženemo odjemalca 1C:Enterprise iz drugega računalnika in dodamo obstoječo informacijsko bazo newdb. Ne pozabite na licence in zaščito programske/strojne opreme. Zdaj lahko prenesemo test Gilev in izmerimo zmogljivost našega sistema.

Na VirtualBoxu z 1 GB pomnilnika, dvojedrnim procesorjem 2,6 GHz, izdajo 319 1c test Gilev daje 11,42 točke, približno enako kot na CentOS. Pri 16,362 je nekaj več kot 11,60 točke. Optimiziranje nastavitev s čarovnikom za uravnavanje EnterpriseDB ni dalo opaznega povečanja (11.66 in 11.62), čeprav je lahko na splošno koristno. :)

3. Rutinsko delo na strežniku PostgreSQL.

Rezerva.

Zaženite skrbniški pripomoček pgAdmin III in z desno miškino tipko kliknite želeno zbirko podatkov. Izberite "Varnostno kopiranje".
Izberite obliko (Po meri (stopnja stiskanja od 0 do 9), Tar, Enostavno, Katalog). Kar zadeva stopnjo stiskanja, se najbolj stisne »format po meri« katere koli stopnje stiskanja, nato »imenik«, nato »preprost« in na koncu »tar«. Določimo kodiranje UTF8, ime vloge je postgresql. Vse dodatne možnosti pustimo privzete. Kliknite gumb »Varnostno kopiranje«. V polju »Sporočila« je prikazan seznam vseh izvedenih operacij s kodo za dokončanje. Če je 0, potem uspeh. Tukaj si lahko tudi ogledate, kako zagnati podobno operacijo iz ukazne vrstice.

F)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --compress 9 --encoding UTF8 --verbose --file "G:\Backups\gilev_dump.backup" "newdb"

V skladu s tem avtomatski skript Rezervni izvod, ki ga dodamo razporejevalniku, je lahko videti nekako takole:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --port 5432 --uporabniško ime "postgres" --role "postgres" --no-password --format custom --blobs --compress 9 --encoding UTF8 --verbose --file "G:\Backups\gilev_dump_%date:~0,2%_%date:~3,2%_%date:~6,4% .backup" "newdb"

Obnovitev.

Za obnovitev izberemo bazo podatkov, iz katere želimo obnoviti podatke varnostno kopijo, po možnosti prazna. Z desno miškino tipko kliknite in izberite »Obnovitev«. Nastavite varnostno kopijo, ime vloge: postgres, kliknite »Obnovi«
Uporaba ukazne vrstice:

"C:\Programske datoteke (x86)\pgAdmin III\1.16\pg_restore.exe" --gostitelj 192.168.1.200 --vrata 5432 --uporabniško ime "postgres" --dbname "testdb" --role "postgres" --no -password --verbose "G:\Backups\gilev_dump_26_09_2012.backup"

kjer je testdb prazna baza podatkov, v katero se obnovi arhiv varnostne kopije.

Vzdrževanje:

Ukaz VACUUM:

Zaporedoma očisti vse tabele trenutno povezane baze podatkov, izbriše začasne podatke in sprosti prostor na disku. Najpogosteje se ukaz VACUUM izvede ravno zato, da pridobimo največjo količino prostega prostora na disku in povečamo hitrost dostopa do podatkov.

VAKUUM— označi prostor, ki ga zasedajo stare različice zapisov kot prost. Uporaba te različice ukaza praviloma ne zmanjša velikosti datoteke, ki vsebuje tabelo, ampak vam omogoča, da preprečite njeno nenadzorovano rast, tako da jo popravite na neki sprejemljivi ravni. Pri izvajanju VACUUM je možen vzporedni dostop do tabele, ki se obdeluje. Več jih je dodatne možnosti z uporabo VAKUUMA: VAKUUM POLNI, VAKUUM ZAMRZNI, VAKUUM ANALIZA.

VAKUUM POLN poskuša odstraniti vse stare različice zapisov in s tem zmanjšati velikost datoteke, ki vsebuje tabelo. Ta možnost ukaza popolnoma zaklene tabelo, ki se obdeluje.

VAKUUMSKO ZAMRZOVANJE -Če VACUUM FULL odstrani "smeti" iz tabel in premakne zapise tako, da so tabele kompaktno nameščene na disku in so sestavljene iz najmanjšega števila fragmentov, medtem ko stiskanje traja dolgo in blokira zapise, potem VACUUM FREEZE preprosto odstrani "smeti" iz tabel, vendar se sami zapisi ne premikajo, zato je hitrejši in ne blokira pisanja. Trenutno je to možnost nadomeščena z avtovakuumom - avtomatskim zbiranjem smeti v postgresql.conf plus več dodatnih možnosti, ki razširjajo funkcionalnost:

avtovakuum=vklopljen# Omogoča samodejno zbiranje smeti.
log_autovacuum_min_duration = -1# Nastavitev na nič zabeleži vsa dejanja samodejnega vakuumiranja. Minus ena (privzeto) prepoveduje izhod v dnevnik. Na primer, če nastavite vrednost
enak 250 ms, bodo zabeležena vsa dejanja samodejnega vakuumiranja in analiziranja, ki trajajo 250 ms ali več. Omogočanje te nastavitve je lahko koristno za sledenje samodejnemu vakuumu.
To možnost je mogoče nastaviti samo v datoteki postgresql.conf ali v ukazna vrstica strežnik.
avtovacuum_naptime = 10 min# Čas v sekundah, po katerem se baza podatkov preveri glede potrebe po zbiranju smeti. Privzeto se to zgodi enkrat na minuto.
avtovakuumski_prag_vakuuma= 1800 # Mejna vrednost za število izbrisanih in spremenjenih zapisov v kateri koli tabeli, pri kateri pride do zbiranja smeti (VAKUUM).
prag_analize_avtovakuuma= 900 # Prag za število vstavljenih, izbrisanih in spremenjenih zapisov v kateri koli tabeli, pri prekoračitvi katerega se začne postopek analize (ANALIZA).
faktor_razsežnosti_vakuuma_vakuuma= 0,2 # Odstotek spremenjenih in izbrisanih zapisov glede na tabelo, nad katerim se sproži zbiranje smeti.
faktor_razsežnosti_analize_avtovakuuma= 0,1 # Enako kot prejšnja spremenljivka, vendar glede na analizo.
ANALIZA PODTLAKA— Če ima zbirka podatkov tabele, v katerih se podatki ne spreminjajo ali brišejo, ampak samo dodajajo, potem lahko za take tabele uporabite ločen ukaz ANALIZA. Ta ukaz je vredno uporabiti tudi za ločeno tabelo, potem ko vanjo dodate veliko število zapisov.

Ukaz ANALIZIRAJ:

Služi za posodobitev informacij o porazdelitvi podatkov v tabeli. Te informacije uporabi optimizator za izbiro najhitrejšega izvedbenega načrta poizvedbe. Običajno se ukaz uporablja v povezavi z ANALIZA PODTLAKA.

Ukaz REINDEX (ponovno indeksiranje):

Uporablja se za ponovno gradnjo obstoječih indeksov. Smiselno ga je uporabiti v primeru

— poškodba indeksa;

- stalno povečanje njegove velikosti.

Drugi primer zahteva nekaj razlage. Indeks, tako kot tabela, vsebuje bloke s starimi različicami zapisov. PostgreSQL ne more vedno znova uporabiti teh blokov, zato se indeksna datoteka postopoma povečuje. Če se podatki v tabeli pogosto spreminjajo, lahko raste precej hitro. Če opazite takšno vedenje indeksa, ga konfigurirajte za občasno izvajanje ukaza REINDEX. Upoštevajte: ukaz REINDEX, tako kot VACUUM FULL, popolnoma zaklene tabelo, zato ga je treba izvesti, ko je obremenitev strežnika minimalna.

Vprašanje, kateri DBMS - Postgresql ali MS SQL za 1C je najbolj optimalen - je bilo predmet številnih člankov. V tem članku si bomo ogledali korake optimizacije za oba. DBMS vsakega prodajalca ima svoja priporočila za konfiguracijo in priporočila 1C. Upoštevati je treba, da se lahko glede na opremo, konfiguracijo strežnika in število uporabnikov, ki nastavijo različne obremenitve, podrobnosti postopka optimizacije DBMS za 1C in izvajanja priporočil spremenijo.

Nastavitev PostgreSQL za 1C

Izkušnje z delovanjem podatkovnih baz 1C na PostgreSQL so pokazale, da sta bila najvišja zmogljivost in optimalna zmogljivost 1C in PostgreSQL dosežena na Linuxu, zato je priporočljivo, da ga uporabite. Toda ne glede na operacijski sistem je pomembno vedeti, da so privzete nastavitve, določene ob namestitvi PostgreSQL, namenjene samo zagonu strežnika DBMS. O kakršnem koli industrijskem izkoriščanju ne more biti govora! Naslednji korak po zagonu bo optimizacija PostgreSQL za 1C:

  • Najprej onemogočimo varčevanje z energijo (sicer se lahko zakasnitve odzivov iz baze podatkov nepredvidljivo povečajo) in prepovemo zamenjavo skupnega pomnilnika.
  • Konfiguriramo osnovne parametre strežnika DBMS (priporočila za konfiguracijo so dovolj podrobno opisana tako na uradni spletni strani prodajalca kot pri 1C, zato se bomo osredotočili le na najpomembnejše).
  • Standardna priporočila podjetja 1C predlagajo onemogočanje mehanizmov HyperThreading. Toda testiranje Postgres-pro na strežnikih z omogočenim SMT (simultano multi threading) je pokazalo drugačne rezultate.
Nastavitev shared_buffers na RAM/4 je privzeto priporočilo, vendar primer strežnika Sql nakazuje, da več pomnilnika kot mu je dodeljenega, boljša je njegova zmogljivost (z onemogočenim izpiranjem strani). To pomeni, da več strani s podatki se nahaja v RAM-u, manj je dostopov do diska. Postavlja se vprašanje: zakaj tako majhen predpomnilnik? Odgovor je preprost: če je shared_buffers velik, se nekatere neuporabljene strani zamenjajo na disk. Toda kako slediti trenutku, ko se ponastavitev ustavi in ​​je indikator parametra optimalen? Da bi dosegli in dosegli optimalen indikator shared_buffers, je treba njegovo vrednost v produkciji dnevno dvigniti (če je mogoče) z določenim prirastkom in opazovati, v katerem trenutku se bodo strani začele splakovati na disk (swap se bo povečal).
  • Poleg tega na "velik parameter" negativno vpliva delo s številnimi majhnimi stranmi, ki imajo privzeto velikost 8 Kb. Delo z njimi povečuje režijske stroške. Kaj je mogoče s tem narediti za optimizacijo za 1C? PostgreSQL 9.4 je predstavil parameter huge_pages, ki ga je mogoče omogočiti, vendar samo v Linuxu. Privzeto so vključene ogromne strani s privzeto velikostjo 2048 kB. Poleg tega mora biti podpora za te strani omogočena v OS. Tako lahko z optimizacijo strukture pomnilnika dosežete večji indikator shared_buffers.
  • work_mem = RAM/32..64 ali 32MB..128MB Nastavi količino pomnilnika za vsako sejo, ki bo uporabljena za operacije notranjega razvrščanja, združevanja itd. pred uporabo začasnih datotek. Če je ta obseg presežen, bo strežnik uporabil začasne datoteke na disku, kar lahko znatno zmanjša hitrost obdelave zahtev. Ta parameter se uporablja pri izvajanju operatorjev: ORDER BY, DISTINCT, združevanja itd.
  • Izračunajte dodatno ta parameter lahko storite na naslednji način: (Skupni pomnilnik shared_buffers - pomnilnik za druge programe) / število aktivnih povezav. To vrednost je mogoče zmanjšati s spremljanjem števila ustvarjenih začasnih datotek. Takšne statistične podatke o velikosti in številu začasnih datotek lahko dobite v sistemskem pogledu pg_stat_database.
  • effect_cache_size = RAM - shared_buffers Glavni namen tega parametra je povedati optimizatorju poizvedb, katero metodo pridobivanja podatkov naj izbere: popolno skeniranje ali skeniranje indeksa. Višja kot je vrednost parametra, večja je verjetnost uporabe skeniranja indeksa. V tem primeru strežnik ne upošteva, da lahko podatki ob izvedbi zahteve ostanejo v pomnilniku in jih pri naslednji zahtevi ni treba pridobiti z diska.
  • Namestitev PostgreSQL

    Namestitev 1C na PostgreSQL v sistemu Windows je dokaj preprost postopek. Ko izvajate namestitveni paket, morate določiti kodiranje UTF-8. Pravzaprav je to edina zanimiva niansa in dodatna konfiguracija PostgreSQL za 1C 8.3 iz sistema Windows ni potrebna. Namestitev in konfiguracija PostgreSQL za 1C v operacijskem sistemu Linux lahko povzroči številne težave. Da bi jih premagali, razmislimo o izvajanju (z uporabo distribucijskih kompletov vodilnega ruskega prodajalca PostgreSQL-Pro in podjetja 1C) PostgreSQL na strežniku Ubuntu 16.04 x64.

    Namestitev distribucijskih kompletov 1C za DBMS PostgreSQL

    1. Prenesite določeno mesto distribucijskega kompleta PostgreSQL DBMS:

    2. Naložite PostgreSQL na strežnik;

    3. Namestitveni program PostgreSQL DBMS lahko razpakirate z ukazom:

    tar -xvf postgresql-9.4.2-1.1C_amd64_deb.tar.bz2

    4. Pred namestitvijo distribucijskega kompleta PostgreSQL DBMS preverimo prisotnost zahtevane področne nastavitve v sistemu (privzeto ru_RU.UTF-8):


    5. Če je bil sistem, s katerim bo deloval PostgreSQL, nameščen v jeziku, ki ni ruski, morate ustvariti nove lokalne nastavitve:

    locale-gen ru_RU update-locale LANG=ru_RU.UTF8 dpkg-reconfigure locales

    6. Če je zahtevana lokalizacija še vedno na voljo, jo privzeto namestite:

    locale –a nano /etc/default/locale Zamenjajte vsebino z LANG=ru_RU.UTF-8

    7. Po ponovnem zagonu namestite potrebne pakete za našo različico PostgreSQL:

    apt-get namestite libxslt1.1 ssl-cert

    8. Paket PostgreSQL različice 9.4.2-1.1C je povezan z različico paketa libicu libicu48. Zahtevane različice ni več v repozitoriju, vendar jo lahko prenesete;

    9.Prenesite in postavite v imenik, kjer so shranjene prenesene datoteke za PostgreSQL;

    10. Ko gremo v imenik z datotekami PostgreSQL, izvedemo namestitev tako, da zaporedoma vnesemo naslednje ukaze:

    CD<Путь к папке с файлами>dpkg -i libicu48_4.8.1.1-3ubuntu0.6_amd64.deb dpkg -i libpq5_9.4.2-1.1C_amd64.deb dpkg -i postgresql-client-common_154.1.1C_all.deb dpkg -i postgresql-common_154.1.1C_all.deb dp kg -i postgresql-client-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-contrib-9.4_9.4.2-1.1C_amd64.deb

    11.Končano. Distribucijski komplet PostgreSQL DBMS je nameščen.

    Namestitev distribucij PostgreSQL-Pro

    Če želite namestiti strežnik, morate zaporedoma zagnati naslednje ukaze:

    sudo sh -c "echo "deb http:// 1c.postgrespro.ru/deb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/postgrespro-1c.list" wget --quiet -O - ​​​​http:// 1c.postgrespro.ru/keys/GPG-KEY-POSTGRESPRO-1C-92 | sudo apt-key add - && sudo apt-get posodobitev sudo apt-get namestitev postgresql-pro-1c-9.4

    Za dostop do strežnika uredite parametre v datoteki pg_hba.conf

    cd<Путь до каталога pg_hba.conf>cp pg_hba.conf pg_hba.conf.old bash -c "echo "local all postgres trust" > pg_hba.conf" bash -c "echo "host all all all md5" >> pg_hba.conf"

    Sama datoteka ima naslednjo strukturo:


    Datoteka je dobro dokumentirana, vendar angleški jezik. Na kratko si oglejmo glavne parametre:

    • Lokalno lokalna povezava samo preko unixa
    • Gostitelj Povezava TCP/IP
    • Hostsslšifrirana SSL povezava preko TCP/IP (strežnik mora biti zgrajen s podporo SSL, nastavljen mora biti tudi parameter ssl)
    • Hostnossl nešifrirana povezava prek TCP/IP
    • zaupanje priznati brez overitve
    • zavrniti zavrniti brez preverjanja pristnosti
    • geslo zahteva za geslo z jasnim besedilom
    • md5 zahteva za geslo v obliki MD5
    • ldap preverjanje uporabniškega imena in gesla s strežnikom LDAP
    • polmer Preverjanje uporabniškega imena in gesla s strežnikom RADIUS
    • pam preverjanje uporabniškega imena in gesla s storitvijo vtičnika

    Podrobnejše in podrobnejše informacije najdete v dokumentaciji za izdelek PostgreSQL.

    root@NODE2:/home/asd# storitev --status-all |grep postgres [ - ] postgresql root@NODE2:/home/asd# storitev postgresql zagon root@NODE2:/home/asd# storitev --status-all | grep postgres [ + ] postgresql

    Ko končate osnovno namestitev, morate konfigurirati konfiguracijsko datoteko strežnik postgresql.conf, glede na specifiko konfiguracije strežnika PostgreSQL, 1C in Ubuntu strežnika.

    Optimizacija 1C za MS SQL Server

    Namestite Zadnje posodobitve za SQL Sever.

    Operacijski sistem rezervira prostor in ga zapolni z ničlami, kar traja precej dolgo v naslednjih dogodkih:

    • Izdelava baze podatkov;
    • Dodajanje podatkovnih datotek, dnevnika transakcij, v obstoječo bazo podatkov;
    • Povečanje velikosti obstoječe datoteke (vključno z operacijami Autogrow);
    • Obnavljamo baze podatkov ali skupine datotek.

    Se odloča ta problem dodajanje vloge (pod katero se strežnik izvaja) elementu lokalna politika varnost "Izvajanje nalog vzdrževanja glasnosti."

    Če je možno, je treba bazo podatkov TempDB (posebej intenzivno se uporablja v načinu upravljanega zaklepanja RCSI) in dnevnik transakcij razdeliti na različne diske.

    Na strežniku, kjer deluje SQL strežnik, mora biti način varčevanja z energijo nastavljen na "High Performance".

    Mapa z datotekami baze podatkov ne sme biti stisnjena.

    Na zavihku »Pomnilnik« za strežnik nastavimo minimalno raven na 50 % celotnega pomnilnika. Maksimalno izračunamo z eno od formul:

    • Največji pomnilnik = skupna prostornina - velikost glede na OS - velikost za 1C (če obstaja, po predhodni meritvi uporabljenega pomnilnika s števci) oz.
    • Največji pomnilnik = skupna velikost – (1024* skupna velikost/16384).

    Omejimo parameter DOP "Največja stopnja vzporednosti" in ga nastavimo na "1".

    Statistiko posodabljamo po urniku. Začenši z SQL Server 2008, posodabljanje statističnih podatkov povzroči ponovno prevajanje poizvedb in v skladu s tem izbriše proceduralni predpomnilnik, zato ni potrebe po izvedbi ločenega postopka za brisanje proceduralnega predpomnilnika.

    Občasno ponovno indeksiramo tabelo in defragmentiramo indekse.

    Vzpostavimo pravilno politiko rezervacij. Če vam ni treba obnoviti do zadnje točke v času pred zrušitvijo sistema in zadnjih 5 minut ali več ni kritičnih za vaše podjetje, nastavite model obnovitve na »Enostavno«. To bo znatno pospešilo vašo hitrost snemanja. Glavna stvar je, da je diferencirano varnostno kopiranje mogoče dokončati v določenem času.

    Z ustvarjanjem dodatnih podatkovnih datotek dosežemo izboljšave pri delu s TempDB med V/I. Če je logičnih procesorjev manj kot 8, je priporočljivo, da ustvarite podatkovno datoteko za vsak logični procesor. Če je več kot 8 logičnih procesorjev, je priporočljivo, da ustvarite 8 podatkovnih datotek in povečate za eno pri večkratniku 4, ne pozabite oceniti obremenitve TempDB.

    1. nov. 2012 Prednosti uporabe prosto distribuiranega programsko opremo očitno. Na žalost so očitne tudi slabosti – uradne podpore ni, dokumentacija je pogosto protislovna, nepopolna in razpršena. različnih virov. Ta članek vam bo pomagal razumeti postopek namestitve PosgreSQL za 1C:Enterprise 8 in se izogniti pastem, ki niso opisane v uradni dokumentaciji.

    Potrebne komponente za namestitev

    DBMS PostgreSQL se distribuira brezplačno in je vključen v paket dostave aplikacijskega strežnika 1C. Aplikacijski strežnik 1C:Enterprise 8 je na voljo v dveh različicah: 32-bitni in 64-bitni. Postgre zmore oboje.

    Torej imamo pri roki distribucijske komplete:

    • Postgre: postgresql-9_1_2-1_1Cx64.zip, prijazno posredoval 1C.
    • Distribucija aplikacijskega strežnika 1C:Enterprise za Windows x64, različica 8.2.16.368.

    Zdi se, da ne more biti preprostejše - samo zaženite in namestite. Enostavno! Toda namestitev v standardnem načinu bo dala eno majhno omejitev: gruča se bo nahajala v mapi »Programske datoteke«. Vsem ne bo všeč. Razmislimo o dveh možnostih namestitve, preprosti in napredni.

    Članek je razdeljen na 5 sklopov:

    1) Namestitev strežnika 1C.

    2) Namestite PostgreSQL v standardni obliki, ki zadostuje za zagon 1C brez dodatnih nastavitev.

    3) Namestite PostgreSQL in izberite mapo za shranjevanje gruče.

    4) Ustvarjanje nove informacijske baze 1C.

    5) Določanje mape za shranjevanje datotek baze podatkov na strežniku DBMS.

    Pred namestitvijo obvezno preberite celoten članek!

    Namestitev aplikacijskega strežnika 1C

    Zaženemo setup.exe iz mape z distribucijskim kompletom strežnika 1C.

    Če namestite aplikacijski strežnik ne kot storitev, ga boste morali vsakič ročno zagnati. Ta možnost je redko potrebna. Namestimo ga kot storitev in se odločimo, pod katerim uporabnikom se bo zagnal. Iz varnostnih razlogov je bolje, da ustvarite ločenega uporabnika USR1CV82, namesto da dovolite, da se storitev izvaja s polnimi pravicami.

    Po namestitvi aplikacijskega strežnika vas sistem pozove, da namestite gonilnik zaščitnega ključa HASP. Se strinjamo:

    Čakamo na sporočilo:

    Če je sporočilo drugačno, so v sistemu najverjetneje ostali "repi" prejšnjih namestitev gonilnikov HASP. Izbrišite vse in poskusite znova.

    Končano, aplikacijski strežnik 1C:Enterprise 8 smo uspešno namestili.

    Namestitev PostgreSQL v standardni obliki, ki zadostuje za zagon 1C brez dodatnih nastavitev

    Zaženite "postgresql-9.1.2-1.1C(x64).msi"

    Možnosti namestitve vam ni treba spreminjati, 1C bo deloval. Nadalje.

    Postgre, tako kot strežnik 1C, lahko sam ustvari uporabnika, pod katerim boste izvajali storitev. Opozarjam vas na dejstvo, da če navedete račun s skrbniškimi pravicami storitev ne bo delovala pravilno. Ne pozabite ustvariti novega uporabnika.

    Naslednje namestitveno okno.

    Inicializiramo gručo. Če se nahajata naš strežnik baze podatkov in aplikacijski strežnik 1C različne računalnike, nato potrdite polje »Podpri povezave s katerega koli IP-ja«, sicer se ga ne dotikamo. Ne pozabite določiti kodiranja UTF8. Ustvarite superuporabnika DBMS. Nadalje…

    Za začetno delo ne potrebujemo ničesar dodatnega, počistite polje in dokončajte namestitev.

    Rezultat naših prizadevanj je za uporabo pripravljen PostgreSQL. Če smo zadovoljni, da bodo baze podatkov v Program Files\PostgreSQL\9.1.2-1.1C\data, končamo s tem, odpremo baze podatkov in uživamo v procesu. Vendar pogosteje baze podatkov »ležijo« na posebej zasnovanih diskovnih poljih in ne na sistemski disk. Če želite konfigurirati lokacijo podatkov, pred namestitvijo preberite naslednji razdelek.

    Namestitev Postgre z izbiro lokacije za shranjevanje v gruči

    Nadaljujemo z namestitvijo Postgre in izvedemo vse korake, dokler nismo pozvani, da inicializiramo gručo:

    Počistite polje »Initialize database cluster« in kliknite »Naprej«.

    Da, prepričani smo.

    Počistite polje »Zaženi Stack Builder ob izhodu« in dokončajte namestitev.

    1. Potrebno je podeliti polne pravice mapi, v katero smo namestili PostgreSQL, običajno je to C:\Program Files\PostgreSQL

    2. Zaženite cmd kot skrbnik. Če to storite v win7, ga zaženite kot skrbnik.

    3. Ustvarite mapo, v kateri bo shranjena gruča. Na primer d:\postgredata.

    md d:\postgredata

    4. Ročno inicializiramo gručo in navedemo pot, kjer se bo nahajala.

    “C:\Programske datoteke\PostgreSQL\9.1.2-1.1C\bin\initdb.exe” -D d:\postgredata --locale=Russian_Russia --encoding=UTF8 -U postgres

    5. Odstranite storitev PostgreSQL, ki je bila nameščena med namestitvijo.

    sc izbriši pgsql-9.1.2-1.1C-x64

    Kjer je pgsql-9.1.2-1.1C-x64 ime storitve. Če imena ne poznate natančno, si lahko ogledate lastnosti storitve »PostgreSQL Database Server ...« (Start - Nadzorna plošča - Administrativna orodja - Storitve)

    6. Ustvarjajte nova storitev ki označuje naš grozd

    “C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\pg_ctl” register -N pgsql -U postgresql -P geslo -D d:/postgredata

    7. Zdaj pa pojdimo na storitve. Start – Nadzorna plošča – Administracija – Storitve in zaženite našo storitev.

    Ustvarjanje nove baze podatkov 1C na strežniku s PostgreSQL

    Obstaja več možnosti za ustvarjanje baze podatkov. Bazo podatkov lahko poskusite ustvariti prek pgAdmin3, skrbniške konzole strežnika 1C. Tu pa se boste soočili s kopico nerazumljivih vprašanj in kupom napak, odgovore na katere boste iskali dolgo časa. Prepustite to strokovnjakom. Naš cilj je pridobiti delujočo osnovo z minimalnim naporom. Opišimo, kako najlažje to dosežemo.

    Zaženemo odjemalca 1C.

    Kliknite "Dodaj ...".

    Pripravimo ime za bazo podatkov, nato navedemo »Na strežniku 1C: Enterprise«.

    Grozd strežnikov 1C:Enterprise– localhost, če ustvarjamo bazo podatkov na istem računalniku, kjer je nameščen strežnik 1C, ali ime aplikacijskega strežnika 1C, če je na drugem.

    Ime informacijske baze v gruči- v prihodnosti bo to ime navedeno pri povezovanju iz drugih računalnikov.

    Vrsta DBMS– Izberite PostgreSQL.

    Strežnik baze podatkov- navedite ime strežnika PostgreSQL. Če na strežniku ustvarimo bazo podatkov, podamo še localhost.

    Ime baze podatkov– s tem imenom bo ustvarjena baza podatkov v PostgreSQL.

    Uporabnik, geslo– ime uporabnika, ki smo ga določili kot superuporabnika pri namestitvi PostgreSQL. Ne pozabite potrditi potrditvenega polja »Ustvari bazo podatkov, če ne obstaja«.

    Postavlja se vprašanje - kje bo baza podatkov fizično shranjena? V osnovni mapi navedene gruče. Kaj pa, če ne želimo, da leži tam, kjer so vse baze? Ničesar še ne moremo storiti glede tega, ustvarili bomo samo bazo in šli naprej. Nadalje…

    Določanje mape za shranjevanje baze podatkov

    Torej, ustvarili smo bazo. V večini primerov se tukaj namestitev konča. Če pa obstaja veliko baz podatkov in obstaja več diskovnih polj za različne skupine baz podatkov, morate navesti, kje naj bodo baze podatkov fizično nameščene. Če želite to narediti, zaženite pgAdmin3 iz Start - Programi - PostgreSQL. Povežite se z našim strežnikom.

    Ko se prvič povežete, bo Postgre zahteval geslo za uporabnika postgres (ki smo ga ustvarili med namestitvijo).

    Ustvarimo nov TableSpace, to bo mapa, v kateri bodo shranjene naše baze podatkov.

    Določeno mesto shranjevanja datotek baze podatkov. V REDU.

    Zdaj odpremo lastnosti predhodno ustvarjene baze podatkov, katere lokacijo želimo spremeniti.

    Spremenite lastnost Tablespace. Ko kliknete »V redu«, bodo datoteke baze podatkov samodejno premaknjene. pripravljena! Upamo, da vam je bil članek koristen. Če je tako, pustite komentarje in delite povezave do te strani. Hvala vam!