mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-27 08:39:28 +08:00
679 lines
46 KiB
Plaintext
679 lines
46 KiB
Plaintext
|
|
PostgreSQL GyIK Utolsó módosítás dátuma: 2002 Okt 20. Fordítás
|
|
aktualizálása: 2003 január A GyIK karbantartója: Bruce Momjian
|
|
(pgman@candle.pha.pa.us) Fordító: Hornyák László
|
|
(hornyakl.NOSPAM@inf.elte.hu) A legfrissebb verzió itt érhető el
|
|
(angol): http://www.PostgreSQL.org/docs/faq-english.html. Legfrissebb
|
|
magyar nyelvű verzió:
|
|
http://www.rootshell.be/~hornyakl/downloads/postgres_faq/ Platform
|
|
specifikus kérdések:
|
|
http://www.PostgreSQL.org/users-lounge/docs/faq.html.
|
|
_________________________________________________________________
|
|
Általános kérdések 1.1) Mi a PostgreSQL? Hogy kell kimondani? 1.2) Mik
|
|
a PostgreSQL felhasználási feltételei? 1.3) Milyen UNIX operációs
|
|
rendszereken fut PostgreSQL? 1.4) Milyen nem UNIX operációs rendszerek
|
|
elérhetőek? 1.5) Hogyan tudok PostgreSQL-t szerezni? 1.6) Hogyan kapok
|
|
terméktámogatást? 1.7) Melyik a legfrissebb kiadás? 1.8) Milyen
|
|
dokumentáció áll rendelkezésre? 1.9) Hogyan találok információt
|
|
hibákról vagy hiányzó funkcionalításról? 1.10) Hogy tanuljam meg az
|
|
SQL nyelvet? 1.11) A PostgreSQL 2000. év kompatibilis? 1.12) Hogyan
|
|
lehet csatlakozni a fejlesztő csapathoz? 1.13) Hogyan küldjek
|
|
hibajelentést? 1.14) Milyen a PostgreSQL más DBMS-ekkel
|
|
összehasonlítva? 1.15) Hogyan tudom üzletileg segiteni a PostgreSQL-t?
|
|
Felhasználói kliens kérdések 2.1) Van ODBC meghajtó PostgreSQL-hez?
|
|
2.2) Milyen eszközök állnak rendelkezésre PostgreSQL Web
|
|
fejlesztésekhez? 2.3) Van a PostgreSQL-hez grafikus felhasználói
|
|
felület ? Riport generátor? Beágyazott lekérdező nyelv felület? 2.4)
|
|
Milyen programozási nyelvekkel lehet elérni a PostgreSQL szervert?
|
|
Adminisztrációs kérdések 3.1) Hogyan tudom a PostgreSQL-t
|
|
/usr/local/pgsql -től eltérő helyre installálni? 3.2) AMikor elindítom
|
|
a postmaster-t, egy "Bad System Call"-t vagy core dump-ot kapok.
|
|
Miért? 3.3) Amikor megpróbálom inditani a postmaster-t,
|
|
"IpcMemoryCreate" hibákat kapok. Miért? 3.4) Amikor megpróbálom
|
|
inditani a postmaster-t, "IpcSemaphoreCreate" hibákat kapok. Miért?
|
|
3.5) Hogyan tudom kontrollálni a más gépekről érkező kapcsolat
|
|
kéréseket? 3.6) Hogyan tudom nagyobb teljesítményre hangolni az
|
|
adatbázisomat? 3.7) Milyen hibakereső lehetőségek érhetőek el? 3.8)
|
|
Miért kapok "Sorry, too many clients" hibát csatlakozásnál? 3.9) Mi
|
|
van pgsql_tmp könyvtárban? 3.10) Miért kell dumpolni és újratölteni
|
|
PostgreSQL kiadás váltásánál? Működtetési kérdések 4.1) Mi a különbség
|
|
a bináris és a normál kurzorok között? 4.2) Hogyan tudom select-elni a
|
|
lekérdezés első pár sorát? 4.3) Hogy tudom kilistázni a táblákat vagy
|
|
más dolgokat a PostgreSQL-ben? 4.4) Hogyan tudok eltávolítani egy
|
|
oszlopot egy táblából? 4.5) Mi a maximális mérete egy sornak, egy
|
|
táblának vagy egy adatbázisnak? 4.6) Mekkora adatbázis lemez terület
|
|
szükséges egy tipikus szöveg állomány tárolásához? 4.7) Hogy tudhatom
|
|
meg milyen táblák, indexek, adatbázisok vagy felhasználók vannak
|
|
definiálva? 4.8) A lekérdezéseim lassúak, vagy nem használják az
|
|
indexeket. Miért? 4.9) Hogy tudom ellenőrizni, hogy optimalizálta a
|
|
lekérdezés optimalizáló a lekérdezésem? 4.10) Mi az R-tree index?
|
|
4.11) Mi a Genetic Query Optimizer? 4.12) Hogyan tudok regexp keresést
|
|
és case-insensitive regexp keresést használni? Hogyan tudok indexet
|
|
használni case-insensitive kereséshez? 4.13) Hogyan tudom észlelni egy
|
|
lekérdezésban, ha egy mező NULL? 4.14) Mi a különbség a különböző
|
|
karaktertípusok között? 4.15.1) Hogyan tudok létrehozni automatikusan
|
|
növekvő értékű mezőt? 4.15.2) Hogyan kaphatom meg egy SERIAL beszúrás
|
|
értékét? 4.15.3) A currval() és a nextval() nem teremt holtpont
|
|
veszélyes helyzetet a felhasználók között? 4.15.4) Miért nem
|
|
használódnak fel újra a sequence számok tranzakció abort esetén? Miért
|
|
vannak problémák a serial oszlopok számozásával? 4.16) Mi a OID? Mi a
|
|
TID? 4.17) Mi a PostgreSQL-ben használt kifejezések jelentése? 4.18)
|
|
Miért kapom ezt a hibát: "ERROR: Memory exhausted in AllocSetAlloc()"?
|
|
4.19) Hogyan tudhatom meg PostgreSQL, milyen verziót futtatok? 4.20)
|
|
Miért kapok "invalid large obj descriptor" hibát nagy objektumok
|
|
kezelésénél? 4.21) Hogy hozhatok létre olyan oszlopot, aminek
|
|
alapértelmezett érétke a jelenlegi idő? 4.22) Miért olyan lassúak az
|
|
al-lekérdezéseim IN-nel? 4.23) Hogyan tudok outer join-t végrehajtani?
|
|
4.24) Hogyan tudok több adatbázison végrehajtani lekérdezést? 4.25)
|
|
Hogy tudok több soros vagy oszlopos eredményt visszaadni egy
|
|
funkcióból? 4.26) Miért nem tudom megbizhatóan létrehozni és törölni
|
|
az átmeneti táblákat a PL/pgSQL funkciókban? 4.27) Milyen replikációs
|
|
lehetőségek vannak? 4.28) Milyen kódolási lehetőségek vannak? A
|
|
PostgreSQL kiterjesztése 5.1) Írtam egy felhasználói funkciót. Miért
|
|
core dumpol az adatbázis amikor használom? 5.2) Hogyan lehet új
|
|
adattípusokat és funkciókat hozzáadni a PostgreSQL disztribúcióhoz?
|
|
5.3) Hogyan lehet olyan C funkciót írni, ami Tuple-t ad vissza? (több
|
|
soros több oszlopos eredmények) 5.4) Megváltoztattam egy forrás
|
|
állományt. Miért nem változik a bináris újrafordítás után?
|
|
_________________________________________________________________
|
|
Általános kérdések 1.1) Mi a PostgreSQL? Hogy kell kimondani? Így
|
|
ejstd ki: Post-Gres-Q-L. (Vagy talán inkább töltsd le a kis mp3-at a
|
|
PostgreSQL homepage-ről) A PostgreSQL a POSTGRES adatbázis management
|
|
rendszer egy kiegészítése, ami egy következő generációs DBMS kutatási
|
|
prototípus. Megtartja a POSTGRES adatmodellét és gazdag adattípus
|
|
választékát, de a PostQuel lekérdező nyelvet az SQL egy kiterjesztett
|
|
verziójával helyettesíti. A PostgreSQL szabad és a teljes forráskód
|
|
hozzáférhető. A PostgreSQL fejlesztését egy csapat végzi, amelynek
|
|
minden tagja megtalálható a PostgreSQL fejlesztői levelezési listán. A
|
|
jelenlegi koordinátor Marc G. Fournier (scrappyp@PostgreSQL.org). Ez a
|
|
csapat felelős minden fejlesztésért. A PostgreSQL 1.01 alkotói Andrew
|
|
Yu és Jolly Chen voltak. Sokan járultak hozzá portolással,
|
|
teszteléssel, hibakereséssel és fejlesztéssel. Az eredeti Postgres
|
|
kód, amiből a PostgreSQL származik Michael Stonebraker professzor
|
|
irányítása alatt fejlesztettek az egyetem programozói, tanulói és
|
|
végzett tanulói. A szoftver ereeti neve Postgres volt. Amikor SQL
|
|
funkcionalítással egészítették ki 1995-ben, a nevét Postgres95-re
|
|
változtatták. 1996 végén kapta mai nevét. 1.2) Mik a PostgreSQL
|
|
felhasználási feltételei? Az eredeti angol copyright szöveg:
|
|
-------------------- PostgreSQL is subject to the following COPYRIGHT:
|
|
PostgreSQL Data Base Management System Portions copyright (c)
|
|
1996-2002, PostgreSQL Global Development Group Portions Copyright (c)
|
|
1994-6 Regents of the University of California Permission to use,
|
|
copy, modify, and distribute this software and its documentation for
|
|
any purpose, without fee, and without a written agreement is hereby
|
|
granted, provided that the above copyright notice and this paragraph
|
|
and the following two paragraphs appear in all copies. IN NO EVENT
|
|
SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT,
|
|
INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING
|
|
LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS
|
|
DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED
|
|
OF THE POSSIBILITY OF SUCH DAMAGE. THE UNIVERSITY OF CALIFORNIA
|
|
SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
|
|
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND
|
|
THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE
|
|
MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. The
|
|
above is the BSD license, the classic open-source license. It has no
|
|
restrictions on how the source code may be used. We like it and have
|
|
no intention of changing it. -------------------- Ami nagyon
|
|
leegyszerűsítve azt jelenti, hogy jogod van használni a szoftvert
|
|
mindenféle ellenszolgáltatás (pénz, stb) nélkül, a forrás kódot
|
|
módosíthatod, és továbbadhatod, DE semmilyen, a szoftver használatából
|
|
következő károsodásért nem vállal garanciát a fejlesztő. A fenti a BSD
|
|
licensz, egy klasszikus nyilt-forráskód licensz. Nem tartalmaz
|
|
megszorításokat arra, hogy a forráskódot hogyan használod fel.
|
|
Kedveljük ezt a licensz formát és nem áll szándékunkban
|
|
megváltoztatni. 1.3) Milyen UNIX operációs rendszereken fut
|
|
PostgreSQL? Általában minden UNIX-kompatibilis operációs rendszer
|
|
képes arra hogy futtassa a PostgreSQL-t. Azokat a platformokat, amiken
|
|
tesztelték a kiadást megtalálhatod a installációs utasítások között.
|
|
1.4) Milyen nem UNIX operációs rendszerek elérhetőek? Kliens A libpq C
|
|
függvénykönyvtárat, a psql-t és más felületeket le lehet úgy
|
|
fordítani, hogy fussanak MS Windows operációs rendszereken. Ebben az
|
|
esetben a kliens MS Windows-on fut és TCP/IP segítségével kommunikál a
|
|
Unixon futó szerverrel. A "win32.mak" állomány a kiadás része, ennek
|
|
segítségével lehet Win32 platformokra lefordítani a libpq-t és a
|
|
psql-t. A PostgreSQL ODBC kliensekkel is képes kommunikálni. Szerver
|
|
Az adatbázis szerver Cygwin segítségével fut Windows NT és Win2k
|
|
rendszereken. További információ található a pgsql/doc/FAQ_MSWIN
|
|
állományban és a MS Windows FAQ-ban a következő helyen:
|
|
http://www.PostgreSQL.org/docs/faq-mswin.html. Natív MS Windows
|
|
NT/2000/XP portok jelenleg fejlesztés alatt állnak. 1.5) Hogyan tudok
|
|
PostgreSQL-t szerezni? Az elsődleges anonim ftp oldal:
|
|
ftp://ftp.PostgreSQL.org/pub. A tükör oldalak listája megtalálható a
|
|
fő weboldalunkon. 1.6) Hogyan kapok terméktámogatást? Az elsődleges
|
|
lista a pgsql-general@postgresql.org. Ez használható a PostgreSQL-lel
|
|
kapcsolatos párbeszédekre. Ha fel szeretnél íratkozni, küldj egy
|
|
levelet a következő tartalommal (nem tárggyal) a
|
|
pgsql-general-request@postgresql.org címre: subscribe end Van egy
|
|
hibákkal kapcsolatos levelezési lista is:
|
|
pgsql-bugs-request@PostgreSQL.org a következő tartalommal: subscribe
|
|
end A fejleszt?i levelezési lista:
|
|
pgsql-hackers-request@PostgreSQL.org a következő tertalommal:
|
|
subscribe end Egyéb levelezési listák találhatóak a weboldalunkon:
|
|
http://www.PostgreSQL.org Van egy IRC csatorna is #PostgreSQL néven
|
|
ahol felteheted kérédseid. A következő unix paranccsal csatlakozhatsz:
|
|
irc -c '#PostgreSQL' "$USER" irc.phoenix.net. A kereskedelmi
|
|
terméktámogatást nyújtó cégek listája elérhetö itt:
|
|
http://www.PostgreSQL.org/users-lounge/commercial-support.html 1.7)
|
|
Melyik a legfrissebb kiadás? A legfrissebb PostgreSQL kiadás a 7.3. A
|
|
tervek szerint minden negyedik hónapban van új kiadás. 1.8) Milyen
|
|
dokumentáció áll rendelkezésre? Számos kézikönyv, man oldalak és kis
|
|
teszt példák találhatóak a kiadásban a doc/ könyvtár alatt. Az
|
|
interneten is olvashatod a dokumentációt a következő címen:
|
|
http://www.PostgreSQL.org/users-lounge/docs/. Két PostgreSQL könyv
|
|
érhető el az interneten a http://www.PostgreSQL.org/docs/awbook.html
|
|
és a http://www.commandprompt.com/ppbook/ címeken. A megvásárolható
|
|
könyvek listája itt található: http://www.ca.PostgreSQL.org/books/. A
|
|
PostgreSQL-lel kapcsolatos technikai jellegű cikkek gyűjteménye:
|
|
http://techdocs.PostgreSQL.org/. A psql parancs rendelkezik néhány \d
|
|
utasítással, amellyekkel listázhatóak az operátorok, a funkciók, stb.
|
|
A website is tartalmaz további dokumentációkat. 1.9) Hogyan találok
|
|
információt hibákról vagy hiányzó funkcionalításról? A PostgreSQLaz
|
|
SQL-92 szabvány egy kiegészítése. Nézd meg a TODO listákat ha
|
|
érdekelnek az ismert hibák. 1.10) Hogy tanuljam meg az SQL nyelvet? A
|
|
PostgreSQL könyv a http://www.PostgreSQL.org/docs/awbook.html címen
|
|
tartalmaz SQL alapokat. Elérhető egy másik SQL könyv is a
|
|
http://www.commandprompt.com/ppbook címen. Egy szép oktató anyag
|
|
található a http://www.intermedia.net/support/sql/sqltut.shtm, a
|
|
http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM
|
|
és a http://sqlcourse.com oldalakon. Egy másik lehetőség a "Tanítsd
|
|
magad 21 nap alatt SQL-re, második kiadás" a
|
|
http://members.tripod.com/er4ebus/sql/index.htm. Sok felhasználónak
|
|
tetszett a gyakorlati SQL könyv ("The Practical SQL Handbook"). 1.11)
|
|
A PostgreSQL 2000. év kompatibilis? Igen, könnyedén kezeli a 2000
|
|
utáni és időszámításunk elött 2000 elötti dátumokat is. 1.12) Hogyan
|
|
lehet csatlakozni a fejlesztő csapathoz? Elösször is töltsd le a
|
|
forráskódot, és olvasd el a PostgreSQL fejlesztői dokumnetációt a web
|
|
oldalunkon vagy a kiadásban. Ezután íratkozz fel a pgsql-hackers és a
|
|
pgsql-patches levelezési listákra. Végül pedig küldj be magas
|
|
szinvonalú patch-eket a pgsql-patches listára. Van egy pár ember,
|
|
akiknek commit privilégiumuk a PostgreSQL CVS fán. Ők olyan sok magas
|
|
szinvonalú patch-et küldtek be, hogy az addigi csapat már nem tudta
|
|
követni, és nem volt kétségünk arról, hogy a patch-ek amiket ők
|
|
küldenek jó minőségű. 1.13) Hogyan küldjek hibajelentést? Látogass el
|
|
a BugTool oldalra: http://www.PostgreSQL.org/bugs/bugs.php Itt
|
|
megtalálod követendő utasításokat. Ellenőrizd az ftp oldalunkon is,
|
|
hogy nincs-e újabb verzió vagy folt. ftp://ftp.PostgreSQL.org/pub
|
|
1.14) Milyen a PostgreSQL más DBMS-ekkel összehasonlítva? Számos
|
|
nézőpontból lehet vizsgálni a szoftvert: képességek, teljesítmény
|
|
megbízhatóság, támogatottság és ár. Képességek A PostgreSQL
|
|
rendelkezik a nagy, kereskedelmi DBMS-ek képességeivel: tranzakciók,
|
|
al-lekérdezések, triggerek, nézetek, külső kulcsok, integrítás és
|
|
kifinoult zármechanizmusok. Van néhány képessége, ami a kereskedelmi
|
|
adatbázisokból hiányzik, mint például a felhasználó által definiált
|
|
típusok, öröklődés, szabályok és verzió kontroll a zárolási viták
|
|
redukálásáért. Teljesítmény A PostgreSQL teljesítménye hasonlít a
|
|
kereskedelmi és más nyílt adatbázis szerverekéhez. Lehet bizonyos
|
|
esetekben lassabb, másokban gyorsabb. A MySQL nevű tanuló RDBMS
|
|
például gyorsabban hajt végre insert/update műveleteket, mivel a
|
|
tranzakciókat elsumákolja. Persze a MySQL nem rendelkezik a képességek
|
|
részben felsoroltak nagy részével. Mi a megbízhatóságra és a
|
|
képességekre építünk, bár a teljesítmény is nő minden kiadással. Van
|
|
egy érdekes oldal a MySQL és a PostgreSQL összehasonlításával a
|
|
http://openacs.org/philosophy/why-not-mysql.html címen. Megbízhatóság
|
|
Tudjuk hogy ha egy DBMS nem megbízható, akkor teljesen haszontalan.
|
|
Igyekszünk jól tesztelt, stabil kódot kiadni, amiben a lehető
|
|
legkevesebb hiba van. Minden kiadás elött eltellik legalább 1 hónap
|
|
béta teszt, és a kiadási történet is azt mutatja, hogy stabil kódot
|
|
adunk ki, ami készen áll a produktív felhasználásra. Úgy gondoljuk,
|
|
felülmúlunk más adatbázis szoftvereket ezen a téren. Támogatás A
|
|
levelezési listáink kapcsolatot teremtenek a fejlesztők és
|
|
felhasználók csoportjával , akik segítenek a problémák megoldásában.
|
|
Bár nem tudjuk garantálni hogy ki tudjuk javítani a hibát, más,
|
|
kereskedelmi adatbázis cégek sem tudják. A fejlesztő csoport közvetlen
|
|
elérési lehetősége, a közösség, a dokumentáció és a forráskód gyakran
|
|
támogatást biztosít, mint más adatbázisoknál. Van kereskedelmi,
|
|
alkalmi támogatás azoknak, akiknek szüksége van rá (lásd: 1.6). Ár A
|
|
PostgreSQL szabad bármilyen felhasználásra, akár kereskedelmire is. A
|
|
termékhez hozzáadhatod a saját forráskódjaidat korlátozás nélkül,
|
|
1.15) Hogyan tudom üzletileg segiteni a PostgreSQL-t? A PostgreSQL
|
|
első osztályú infrastruktúrával rendelkezik, amit 1996-ban indítottunk
|
|
el. Mindent Marc Fourniernek köszönhetünk, aki létrehozta és
|
|
karbantartja a rendszert. A minőségi infrastruktúra nagyon fontos egy
|
|
nyilt forrású szoftver esetében. Megvéd az olyan fennakadásoktól,
|
|
amelyek komoly késéseket okoznak a fejlesztésekben. Természetesen ez
|
|
az infrastruktúra nem olcsó. Számos havi és állandó kiadásunk van. Ha
|
|
a cégednek van pénze, amivel támogatná erőfeszítéseinket, kérlek
|
|
látogass el a http://store.pgsql.com/shopping/ oldalra. Bár a weboldal
|
|
"PostgreSQL, Inc"-ként említi, a hozzájárulások kizárólag a PostgreSQL
|
|
fejlesztésre értendóek, és nem egy meghatározott cégnek. Ha jobban
|
|
tetszik, küldhetsz csekket is a kapcsolati címek bármelyikére.
|
|
_________________________________________________________________
|
|
Felhasználói kliens kérdések 2.1) Van ODBC meghajtó PostgreSQL-hez?
|
|
Két ODBC meghajtó érhető el: PsqlODBC és a OpenLink ODBC. A PsqlODBC a
|
|
PostgreSQL kiadás része. További információ található a
|
|
ftp://ftp.PostgreSQL.org/pub/odbc/ oldalon. Az OpenLink ODBC-t a
|
|
http://www.openlinksw.com címről töltheted le. Ez az ő szabványos ODBC
|
|
kliens szoftverükkel működik, így minden általuk támogatott platformon
|
|
(Win, Mac, Unix, VMS) elérhető lesz a PostgreSQL szerver. Talán olyan
|
|
vevőknek fogják eladni, akik kereskedelmi minőségű terméket
|
|
szeretnének kapni, de a freeware verzió mindig elérhető lesz.
|
|
Kérdéseidet a termékkel kapcsolatban a postgres95@openlink.co.uk címen
|
|
teheted fel. Olvasd el az ODBC fejezetet is a programozók
|
|
kézikönyvében! 2.2) Milyen eszközök állnak rendelkezésre PostgreSQL
|
|
Web fejlesztésekhez? Egy szép bemutató olvasható az adatbázissal
|
|
támogatott web oldalanról a http://www.webreview.com weboldalon. A web
|
|
integrációhoz a PHP egy kiválló szoftver. Letölthető a
|
|
http://www.php.net címről. Komplexebb esetekre sokan használják a Perl
|
|
felületet és a CGI.pm vagy a mod_perl-t. 2.3) Van a PostgreSQL-hez
|
|
grafikus felhasználói felület? Riport generátor? Beágyazott lekérdező
|
|
nyelv felület? Van egy szép PgAccess nevű grafikus felületünk, ami
|
|
riport generátorként is használható. A weboldalát megtalálod a
|
|
http://www.pgaccess.org/ címen. A disztribúció tartalmazza az ecpg
|
|
programot is, ami egy beágyazott SQL lekérdezési felület C nyelvhez.
|
|
2.4) Milyen programozási nyelvekkel lehet elérni a PostgreSQL
|
|
szervert? A következök: * C (libpq) * C++ (libpq++) * Embedded C
|
|
(ecpg) * Java (jdbc) * Perl (DBD::Pg and perl5) * ODBC (odbc) * Python
|
|
(PyGreSQL) * TCL (libpgtcl) * C Easy API (libpgeasy) * PHP ('pg_'
|
|
functions, Pear::DB) További programozási felületek érhetőek el a
|
|
http://www.PostgreSQL.org/interfaces.html és a
|
|
http://gborg.PostgreSQL.org oldalakon.
|
|
_________________________________________________________________
|
|
Adminisztrációs kérdések 3.1) Hogyan tudom a PostgreSQL-t
|
|
/usr/local/pgsql -től eltérő helyre installálni? A configure script
|
|
--prefix paraméterének használatával. 3.2) AMikor elindítom a
|
|
postmaster-t, egy "Bad System Call"-t vagy core dump-ot kapok. Miért?
|
|
Számos probléma lehet, de legelösször ellenőrizd le, hogy a kerneled
|
|
System V kiegészítésekkel rendelkezik-e. A PostgreSQL használja a
|
|
kernel osztott memória és szemafor API-ját. 3.3) Amikor megpróbálom
|
|
inditani a postmaster-t, "IpcMemoryCreate" hibákat kapok. Miért? Vagy
|
|
nincs megfelelően konfigurálva a kerneled osztott memória támogatása
|
|
vagy meg kell nagyobbítanod a maximális osztott memória méretet. A
|
|
pontos méret szükséglet függ az architektúrádtól és attól hogy hány
|
|
buffert és processzt konfigurálsz a postmasternek. Legalább 1 MB
|
|
területre szükséged van. A PostgreSQL Adminisztráció kézikönyvben
|
|
olvashatsz részletesebb információkat az osztott memóriáról és a
|
|
szemaforokról. 3.4) Amikor megpróbálom inditani a postmaster-t,
|
|
"IpcSemaphoreCreate" hibákat kapok. Miért? Ha a hibaüzenet ez: "
|
|
IpcSemaphoreCreate: semget failed (No space left on device)", akkor a
|
|
kerneled konfigurációja nem tesz lehetővé elegendő szemafort. A
|
|
PostgreSQL szerver processzenként 1 szemafort igényel. Egy átmeneti
|
|
megoldás lehet az hogy a postmastert kevesebb maximális processz
|
|
számmal inditod el. Használd a -D paramétert. Egy sokkal megfelelőbb
|
|
megoldás az ha növeled a kerneled SEMMNS és SEMMNI paramétereit. A
|
|
hibás szemaforok is adatázis lerobbanásához is vezethet nagy terhelés
|
|
esetén. Ha a hibaüzenet valami más, lehet hogy nincs szemaforok
|
|
támogatás forditva a kerneledbe. Olvasd el a PostgreSQL
|
|
adminisztrátorok kézikönyvében az osztott memóriáról és a
|
|
szemaforokról szóló fejezetet. 3.5) Hogyan tudom kontrollálni a más
|
|
gépekről érkező kapcsolat kéréseket? Alapértelmezésben a PostgreSQL a
|
|
helyi kapcsolatokat Unix socketekkel valósítja meg. Más gépek nem
|
|
lesznek képesek csatlakozni, ha nem engedélyezed azt -i opcióval a
|
|
postmasternek, és nem állítod be host a alapú azonosítást a
|
|
pg_hba.conf állományban. Ezzel válnak lehetővé a TCP/IP kapcsolatok.
|
|
3.6) Hogyan tudom nagyobb teljesítményre hangolni az adatbázisomat? Az
|
|
indexelés feltétlenül gyorsítja a lekérdezéseket. Az EXPLAIN parancs
|
|
lehetővé teszi hogy lásd, hogy a PostgreSQL miként interpretálja a
|
|
lekérdezést és melyik indexet használja. Ha sok INSERT műveletet
|
|
hajtassz végre, csináld nagy kötegekben a COPY paranccsal. Ez sokkal
|
|
gyorsabb mint az egyedi INSERT parancsok. Másodszor: Azok a műveletek,
|
|
amelyek nincsenek tranzakció blokkon belül, azok saját tranzakciót
|
|
indítanak. Sok műveletet érdemes egy tranzakción belül végrehajtani.
|
|
Ez csökkenti a tranzakció kezelés többletidejét. Az indexeket javasolt
|
|
a nagy adatváltozások elött eltávolítani, majd újra létrehizni. Számos
|
|
teljesítmény javító lehetőség van. Kikapcsolhatod az fsync() műveletet
|
|
a postmaster -o -F opciókval való indításakor. Így nem fog az amugy
|
|
lassú fsync() függvény meghívódni minden tranzakció végén.
|
|
Használhatod a postmaster -B opcióját is az osztott memória szegmens
|
|
méretének növeléséhez. Ha az értéket túl magasra állítod, lehet hogy a
|
|
postmaster nem indul el, mert túllépted az operációs rendszer által
|
|
megengedett méretet. Minden buffer 8K méretű és alapértelmezésban 64
|
|
buffer van. A -S opcióval növelheted a szerver átmeneti rendezésekre
|
|
fenntartott memória területét. Az értéket kilobyteban add meg. Az
|
|
alapértelmezett érték 512K. Használhatod a CLUSTER utasítást is, hogy
|
|
a táblákat egy indexnek megfelelően csoportosítsd. Olvasd el a CLUSTER
|
|
kézikönyv oldalt további részletekért. 3.7) Milyen hibakereső
|
|
lehetőségek érhetőek el? A PostgreSQL számos lehetöséggel rendelkezik
|
|
ami értékes lehet a hiba- keresésnél. Elösször is, futtathatod a
|
|
configure scriptet --enable-cassert opcióval, sok assert()
|
|
funkcióhivás ellenörzi a program futását és megállitja ha valami
|
|
vératlan hiba történik. Mind a postmaster és a postgres számos
|
|
hibakeresö lehetüséggel rendelkezik. Mindig amikor elinditod a
|
|
postmastert, gyözödj meg róla, hogy a kimenetet log állományba küldöd.
|
|
Igy: cd /usr/local/pgsql ./bin/postmaster >server.log 2>&1 & Ez egy
|
|
server.log állományt hoz létre a felsö PostgreSQL könyvtárban. Ez az
|
|
állomány tartlamaz majd számos hasznos információt a szerverrel
|
|
kapcsolatos problémákról és hibákról. A postmaster -d opciójával lehet
|
|
részletesebb hibakeresö információt kapni. A -d opcióhoz meg kell
|
|
határozni egy hiba szintet. Vigyázz, a magas hibakeresö szint nagy log
|
|
állományt okozhat. Ha a postmaster nem fut, akkor futtathatod a
|
|
postgres szervert parancssorból is, és az SQL kifejezést közvetlenül
|
|
ennek adhatod át. Ez csak hibakeresés esetében javasolt. Az új sor a
|
|
kifejezés végét jelenti, nem a pontosvesszö. Ha hibakeresö opciókkal
|
|
forditottad a szervert, használhatsz egy debuggert is hogy lásd hogy
|
|
mi történik. Mivel igy a szervert nem a postmaster inditotta, nem
|
|
többfelhasználós környezetként fut, igy a zárolási és a szerverek
|
|
közötti kommunikációs hiba jelenségek nem jelentkeznek. Ha már fut a
|
|
postmaster, indits egy psql-t, és nézd meg a szerver processz PID-jét!
|
|
Egy debuggert használhatsz a processzhez csatlakozáshoz. Beállithatsz
|
|
töréspontokat és elindithatsz lekérdezéseket. Ha a postgres inditásban
|
|
keresel hibát, a PGOPTIONS környezeti változót állitsd be "-W n"
|
|
értékre. Ez n másodperc várakozást idéz elö, igy tudsz csatlakozni a
|
|
processzhez, el tdsz hejezni töréspontokat, majd folytathatod a
|
|
indítást. A postgres program -s, -A és -t opciói is nagyon hasznosak
|
|
lehetnek hibakeresésnél és teljesítmény mérésnél. Profiling
|
|
lehtöséggel is fordithatod a szervert, hogy lásd melyik funkciók
|
|
foglalják el a futási időt. A szerver profile állományai a
|
|
pgsql/data/base/dbname könzvtárba kerülnek, a kliens profile
|
|
állományok az aktuális könyvtárba. Linuxon ehhez szükséges a
|
|
-DLINUX_PROFILE fordítási direktiva. 3.8) Miért kapok "Sorry, too many
|
|
clients" (Túl sok kliens) hibát csatlakozásnál? Növelned kell a
|
|
postmaster egyidejűleg futtatott szerver processz szám korlátját. Az
|
|
alapértelmezett korlát 32 processz. Ezt növelhetjed úgy, hogy
|
|
újrainditod a postmastert és -N opcióval meghatárotod az új értéket,
|
|
vagy módositod a postgresql.conf-ot. Ne felejtsd el, hogy ha növeled a
|
|
szerver processzek maximális számát, akkor bufferek számát is növelned
|
|
kell, legalább a processzek számának kétszeresére. Nagy processz
|
|
számokesetében valószinüleg a Unix konfigurációs paramétereken is
|
|
növelni kell. Ellenörizd a SHMMAX (az osztott memória szegmensek
|
|
maximális mérete), a SEMMNS és a SEMMNI (a szemaforok maximális
|
|
száma), az NPROC (a processzek maximális száma), a MAXUPRC
|
|
(felhasználónkénti maximális processz szám) és a NFILE és NINODE (a
|
|
megnzitott állománzok maximális száma) paramétereket. A PostgreSQL
|
|
azért korlátozza külön a processz számot, hogy a rendszeredet ne
|
|
terhelhesse meg túlságosan. A PostgreSQL 6.5 verzióban a maximális
|
|
szerver processz szám 64 volt és a módositáshoz bele kellett irni a
|
|
include/storage/sinvaladt.h állományba és újra kellett forditani a
|
|
servert. 3.9) Mi van pgsql_tmp könyvtárban? Ez a könyvtár a lekérdezés
|
|
végrehajtó által létrehezott átmeneti állományokat tartalmazza.
|
|
Például ha egy rendezést kell végrehajtani egy ORDER BY kifejezés
|
|
miatt és a m?velet több memóriát vesz igénybe, mint amennyit a -S
|
|
paraméter megenged, akkor az átmeneti könyvtárban hoz létre egy
|
|
állományt a fennmaradó adat tárolására. Az átmeneti állományok
|
|
többnyire törl?dnek, de meg is maradhat ha például váratlan hibával
|
|
leáll a szerver egy rendezés közben. Inditáskor és leállitáskor ezeket
|
|
az állományokat törli a postmaster. 3.10) Miért kell dumpolni és
|
|
újratölteni PostgreSQL kiadás váltásánál? A PostgreSQL csapat csak
|
|
apróbb változtatásokat hajt végre a kisebb kiadások között, igy ha 7.2
|
|
verzióról állsz át 7.2.1 verzióra, akkor nem szükséges kidumplonod az
|
|
adatbázist. A nagy kiadások esetében (például verzióról 7.3-ra
|
|
áttérésnél) változik a belsiő adatstruktúrák és adatállományok
|
|
formátuma. Ezek a változások gyakran nagyon összetettek, ezért inkáb
|
|
nem tartunk fenn visszafelé kompatibilitást. A dump az adatot
|
|
általános formátumban irja ki, majd az új formátumban lehet azt
|
|
visszatöleni. Azokban a kiadásokban, amelyek között az adat formátum
|
|
nem változik, a pg_upgrade program használható dumpolás és
|
|
helzreállitás nélkül.
|
|
_________________________________________________________________
|
|
Működtetési kérdések 4.1) Mi a különbség a bináris és a normál
|
|
kurzorok között? Nézd meg a DECLARE dokumentációját. 4.2) Hogyan tudom
|
|
select-elni a lekérdezés első pár sorát? Olvasd el a FETCH
|
|
dokumentációját, vagy használd a SELECT LIMIT-et. Az egész lekérdezést
|
|
végre kell hajtani, még akkor is, ha csak az első pár sort akarod
|
|
megkapni. Gondolj arra, hogy a lekérdezésben lehet ORDER BY is. Ha van
|
|
olyan index, ami megfelel az ORDER BY kifejezésednek, a PostgreSQL
|
|
képes lehet az elsö néhány rekord visszaadására, vagy a teljes
|
|
lekérdezésnek le kell futnia, amig a kért rekordok le nem
|
|
generálódnak. 4.3) Hogy tudom kilistázni a táblákat vagy más dolgokat
|
|
a PostgreSQL-ben? Elolvashatod a psql forrás kódjában a
|
|
pgsql/src/bin/psql/describe.c állományban. Ez SQL parancsokat
|
|
tartalmaz, amelyek azokat a kimeneteket állitják elö, amiket a per
|
|
jellel kezdödö parancsok adnak vissza. 4.4) Hogyan tudok eltávolítani
|
|
egy oszlopot egy táblából? Ez a funkcionalitás a 7.3 verziótül kezdve
|
|
érhetö el az ALTER TABLE DROP COLUMN -nal. A régebbi vertiókban igy
|
|
lehet végrehajtani: BEGIN; LOCK TABLE old_table; SELECT ... -- minden
|
|
oszlopot, kivétel amit törölni szeretnél INTO TABLE new_table FROM
|
|
old_table; DROP TABLE old_table; ALTER TABLE new_table RENAME TO
|
|
old_table; COMMIT; 4.5) Mi a maximális mérete egy sornak, egy táblának
|
|
vagy egy adatbázisnak? A korlátok: adatbázis: korlátlan (1 TB az
|
|
általunk ismert lagnagyobb) tábla: 16 TB rekord/sor 1.6TB mezö 1 GB a
|
|
tábla sorainak száma: korlátlan a tábla oszlopainak száma: 250-1600 az
|
|
oszlop nevektől függöen A tábla indexeinek száma: korlátlan
|
|
Természetesen nem igazán korlátlan, de a tárterület, memória és egyéb
|
|
külsö tényezök korlátozzák. A teljesitmény romolhat, ha ezek az
|
|
értékek szokatlanul nagyok. A 16 TB-os legnagyobb tábla méret nem
|
|
igényel nagy állomány támogatást. A nagy táblák több 1 GB méretü
|
|
állományba kerölnek, igy az állomány rendszer korlátai nem lényegesek.
|
|
A maximális tábla méret és az oszlopok maximális oszlop szám
|
|
növelhetö, ha az alapértelmezett blokkméretet 32k-ra növeled. 4.6)
|
|
Mekkora adatbázis lemez terület szükséges egy tipikus szöveg állomány
|
|
tárolásához? A PostgreSQL akár a szöveg állomány helyigénzének
|
|
ötszörösét is elfoglalhaja. Képzelj el például, egy 100.000 soros
|
|
szöveget, aminek minde sora egy számból és egy szövegből áll. Tegyük
|
|
el, hogy átlagosan 20 byte hosszú szövegek. Ez a szövegállomány
|
|
körülbelül 2.8 MB helyet foglalna el. A tábla ami a fenti
|
|
adatszerkezetet eltárolná, körülbelül 6.4 MB-os lenne. Ezt a
|
|
következöképpen számolhatjuk ki: 36 byte: sor fejléc 24 byte: egy int
|
|
mezö + egy szöveg mezö 4 byte: mutato
|
|
--------------------------------------- 64 byte soronkent. Az adat
|
|
oldal mérete a PostgreSQL-ben 8192 byte, igy 8192 / 64 = 128 rekord
|
|
adatbázis oldalanként (lefelé kerekitve). 100000 rekord / 128 rekord
|
|
oldalanként = 782 adat oldal (felelé kerekitve). 782 adatbázis oldal *
|
|
8192 byte olalanként = 6,406,144 byte (6.4 MB) Az indexek nem
|
|
foglalnak túl sokat, de tartalmazzák az indexelt adatot, igy ezek is
|
|
lehetnek nagyok. A NULL értékek bittérképben vannak tárolva, igy kevés
|
|
helyet foglanak. 4.7) Hogy tudhatom meg milyen táblák, indexek,
|
|
adatbázisok vagy felhasználók vannak definiálva? A psql-ben találsz
|
|
számos '\' karakterrel kezdödö utasítást az ilyen információk
|
|
listázására. A '\?' segitségével tudot kilistázni ezeket a
|
|
parancsokat. Ezen kivül vannak rendszer táblák, amelyek nevei 'pg_'
|
|
-vel kezdödnek. Próbáld ki a pgsql/src/tutorial/syscat.source
|
|
állományt is. Ez sok példát tartalmaz az rendszertáblákon végrehajtott
|
|
SELECT-ekröl. 4.8) A lekérdezéseim lassúak, vagy nem használják az
|
|
indexeket. Miért? Az indexeket nem használja a szerver minden
|
|
lekérdezésnél automatikusan. Csak akkor használ indexet, ha a tábla
|
|
mérete egy megadott alsó határ felett van, és a lekérdezés csak a
|
|
sorok egy kis részét érinti. Ez azért van, mert a véletlen hozzáférés
|
|
még mindig lassabb lehet mint az tábla szekvenciális olvasása. Hogy a
|
|
PostgreSQL meg tudja határozni hogy kell-e indexet használni, léteznie
|
|
kell egy statisztikának a tábláról. Ez a statisztikai adatok a VAACUM
|
|
ANALYZE vagy az egyszerű ANALYZE műveletek során jönnek létre. A
|
|
statisztikai adatok felhasználásával az optimalizáló meg tudja
|
|
határozni, hogy hány sor van a táblában, és el tudja dönteni, hogy
|
|
használjon-e indexet. A statisztiaki adatgyüjtést időnként végre kell
|
|
hajtani, ahogy a tábla adatai változnak. Az indexeket normális esetben
|
|
nem használja az ORDER BY vagy az OUTER JOIN. A szekvenciális olvasás
|
|
általában gyorsabb, mint az index keresés egy nagy táblában. Bár a
|
|
LIMIT az ORDER BY-val kombinálva használhat indexet, mert a tábla csak
|
|
kis része érintett. Bár a MIN és MAX SQL funkciók sem használják az
|
|
indexeket, ezeket az értékeket egy ORDER BY + LIMIT lekérdezéssel is
|
|
le lehet kérdezni: SELECT col FROM tab ORDER BY col [ DESC ] LIMIT 1;
|
|
Amikor helyettesítő jel operátorokat használsz, mint a LIKE kulcsszó
|
|
vagy a ~, az indexeket csak bizonyos körülmények között lehet
|
|
használni: * A kereső string kezdete a keresési minta elején kell hogy
|
|
legyen. például: + A LIKE minták nem kezdődhetnek % jellel. + ~
|
|
(regexp) kifejezések nem kezdődhetnek ^ jellel. * A keresési kifejezés
|
|
nem kezdődhet karakter osztállyal. * A case-insensitive keresés
|
|
(ILIKE, ~*) nem használnak indexet ehelyett funkcionális indexet
|
|
használnak, amit a 4.12 pontban találhatsz. * Az alapértelmezett C
|
|
hellyel kell futtatni az initdb-t. 4.9) Hogy tudom ellenőrizni, hogy
|
|
optimalizálta a lekérdezés optimalizáló a lekérdezésem? Olvasd el a
|
|
dokumentáció EXPLAIN-ról szóló részét. 4.10) Mi az R-tree index? Az
|
|
R-tree index a térbeli adat indexelésére alkalmas. Egy hash index nem
|
|
képes tartomány keresésekre. A B-tree index csak egy dimenzión kezeli
|
|
a tartomány kereséseket. Például ha az indexet egy pont (point
|
|
adattípus) típusú mez.re építjük, gyorsabban kezeli az olyan jellegü
|
|
lekérdezéseket, mint egy adott körben található pontok. Az R-tree
|
|
tervezési mintát eredetileg leíró szöveg: Guttman, A. "R-trees: A
|
|
Dynamic Index Structure for Spatial Searching." Proceedings of the
|
|
1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57. Ezt olvashatod
|
|
Stonebraker "Readings in Database Systems" c. könyvében. A beépített
|
|
R-tree kezelni tudják a sokszögeket (polygon adattípus) és a dobozokat
|
|
(box). Elméletileg, az R-tree kiterjeszthető további dimenziókra is.
|
|
Gyakorlatilag ezen dolgoznod kell egy kicsit, és még nincs
|
|
dokumentációnk arról hogy az hogyan működik. 4.11) Mi a Genetic Query
|
|
Optimizer? A GEQO modul a lekérdezés optimalizáció sebességét növeli
|
|
nagy mennyiségű tábla összekapcsolása esetén. Lehetővé teszi a nagy
|
|
lekérdezések végrehajtását nem teljes kereséssel. 4.12) Hogyan tudok
|
|
regexp keresést és case-insensitive regexp keresést használni? Hogyan
|
|
tudok indexet használni case-insensitive kereséshez? A ~ operátor hajt
|
|
végre reguláris kifejezés (regexp) értelmezést, a ~* ennek
|
|
case-insensitive változata. A LIKE case-insensitive változata az
|
|
ILIKE. A case-insensitive egyenlőség műveleteket általában igy hajtjuk
|
|
végre: SELECT * FROM tab WHERE lower(col) = 'abc'; Ez nem fog indexet
|
|
használni, bár létrehozhatsz egy funkció indexet: CREATE INDEX
|
|
tabindex ON tab (lower(col)); 4.13) Hogyan tudom észlelni egy
|
|
lekérdezésben, ha egy mező NULL? Használd "IS NULL"-t és az "IS NOT
|
|
NULL"-t. 4.14) Mi a különbség a különböző karaktertípusok között? Type
|
|
Internal Name Notes --------------------------------------------------
|
|
"char" char 1 character CHAR(n) bpchar blank padded to the specified
|
|
fixed length VARCHAR(n) varchar size specifies maximum length, no
|
|
padding TEXT text no specific upper limit on length BYTEA bytea
|
|
variable-length byte array (null-byte safe) Látni fogod a belső
|
|
elnevezésüket, ha tanulmányozod a rendszertáblákat és néhány
|
|
hibaüzenetet. Az utóbbi négy a "varlena" típusok, ami a tárolásuk
|
|
módjára utal: az első 4 byte a lemezen a hosszúság, a többi az adat. A
|
|
valódi méret tehát nagyobb mint a deklarált hosszúság.Ezek azadatok
|
|
tömöritve tárolódnak el, igy kevesebb helyet foglalnek el az elöre
|
|
számitottnál. A CHAR(n) a legjobb megoldás, ha stabil hosszúságú
|
|
stringet tárolsz. A VARCHAR(n) jó arra az esetekre, ha a hosszúság
|
|
változik, de van felső korlátja. A TEXT típus korlátlan hosszúságú (1
|
|
GB-ig) szövegek tárolására alklamas. A BYTEA bináris adatok tárolására
|
|
van. A teljesitmény mutatói hasonlóak ezenek a típusoknak. 4.15.1)
|
|
Hogyan tudok létrehozni automatikusan növekvő értékű mezőt? A
|
|
PostgreSQL rendelkezik egy SERIAL adattípussal. Ez egy szekvenciát és
|
|
egy indexet hoz létre az oszlopon. Például ez: CREATE TABLE person (
|
|
id SERIAL, name TEXT ); ugyanezt jelenti: CREATE SEQUENCE
|
|
person_id_seq; CREATE TABLE person ( id INT4 NOT NULL DEFAULT
|
|
nextval('person_id_seq'), name TEXT ); CREATE UNIQUE INDEX
|
|
person_id_key ON person ( id ); A szekvenciákkal kapcsolatban olvasd
|
|
el a create_sequence man oldalt. A sor OID-jét is használhatod egyedi
|
|
azonositóként, bár ebben az esetben figyelj a pg_gump használatánál a
|
|
-o opcióra (COPY WITH OIDS, másolás OID-dal), hogy meg?rizd az
|
|
értékeket. 4.15.2) Hogyan kaphatom meg egy SERIAL beszúrás értékét?
|
|
Egy megoldás erre az, ha a nextval() funkcióval megszerzed az értéket
|
|
még mielött beszúrnád az adatot a táblába. Erre itt láthatsz egy
|
|
példát: new_id = execute("SELECT nextval('person_id_seq')");
|
|
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise
|
|
Pascal')"); Esetleg lekérdezheted a szekvencia állapotát a sor
|
|
beszúrása után. execute("INSERT INTO person (name) VALUES ('Blaise
|
|
Pascal')"); new_id = execute("SELECT currval('person_id_seq')"); Végül
|
|
pedig, használhatod a visszaadott OID értéket is, bár ez a lehető
|
|
legkevésbé portolható. Perl DBI-ben, Edmund Mergl DBD::Pg moduljában
|
|
az OID érték használható a $sth->execute() után
|
|
($sth->{pg_oid_status}). 4.15.3) A currval() és a nextval() nem teremt
|
|
holtpont veszélyes helyzetet a felhasználók között? Nem. A currval()
|
|
funkció a szerver processzed által adott értéket adja vissza, nem
|
|
pedig a többi szerver processz által adottat. 4.15.4) Miért nem
|
|
használódnak fel újra a sequence számok tranzakció abort esetén? Miért
|
|
vannak problémák a serial oszlopok számozásával? A párhuzamosság
|
|
fejlesztése érdekében a sorozat számokat kérésre adja ki a szerver
|
|
futó tranzakcióknak, és azokat nem zárja, amig a tranzakció véget nem
|
|
ér. Ez jukakat okoz a számozásokban a visszaforditott tranzakciók
|
|
miatt. 4.16) Mi a OID? Mi a TID? Az OID a PostgreSQL egyedi sor
|
|
azonositója. Minden sor, ami létrejön a szerveren, kap egy OID-t.
|
|
Minden OID, amit az initdb alatt jön létre 16384 alatt van (lásd
|
|
include/access/transam.h). Minden, felhasználó által létrehozott OID
|
|
legalább ennyi. Alapértelmezésben, az OID nem csak a táblában vagy az
|
|
adatbázisban egyedi, hanem a teljes PostgreSQL adatbázis rendszerben.
|
|
A PostgreSQL az OID-okat a belsö tábláiban használja a sorok táblák
|
|
között összekapcsolásához. Ezek az OID-k használhatóak a rekordok
|
|
azonositására is amikor táblákat csatol össze a szerver (JOIN). Az
|
|
OID-ot használhatod mezö típusként is, és indexelheted is. Az OID
|
|
érték egy központi területröl származik, amit minden szerver processz
|
|
használ. Ha az OID-ot valami másra szeretnéd cserélni: CREATE TABLE
|
|
new_table(old_oid oid, mycol int); SELECT old_oid, mycol INTO new FROM
|
|
old; COPY new TO '/tmp/pgtable'; DELETE FROM new; COPY new WITH OIDS
|
|
FROM '/tmp/pgtable'; Az OID 4 byte-os integer értékként tárolódik, igy
|
|
4 milliárdnál túlcsordul. Még soha senki nem jelezte hogy ez történt
|
|
volna, és ezt a korlátot igyekszünk eltávolitani, még mielött bárki
|
|
észrevenné. A TID a fizikai sorok blokk és offszet címmel való
|
|
azonositására szolgál. A TID változik minden rekord módositás és
|
|
törlés alkalmával. Ezeket az indexek használják hogy a fizikai sort
|
|
gyorsan megtalálják. 4.17) Mi a PostgreSQL-ben használt kifejezések
|
|
jelentése? Néhol a forrás kódban és a dokumnetációban találhatóak
|
|
kifejezések, amelyek általánosabb jelentéssel bírnak. Itt van néhány:
|
|
* tábla (table), reláció (relation), osztály (class) * sor (row),
|
|
rekord (record), tuple (nincs magyar jelentés) * oszlop (column), mezö
|
|
(field), attributum (attribute) * retrieve, select * helyettesit
|
|
(replace), módosit (update) * hozzáfűz (append), beszúr (insert) *
|
|
OID, sorozat érték (serial value) * portal, cursor * range variable,
|
|
tábla név, tábla alias Az általános adatbázis kifejezések
|
|
összefoglalóját itt olvasható:
|
|
http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary
|
|
/glossary.html 4.18) Miért kapom ezt a hibát: "ERROR: Memory exhausted
|
|
in AllocSetAlloc()"? Lehet hogy elfogyott a virtuális memóriád, vagy a
|
|
kerneled erőforrás korlátai alacsonyak. Próbáld ki ezt mielött
|
|
elinditanád a postmastert: ulimit -d 262144 limit datasize 256m A
|
|
shelltől függően ezek közül csak az egyik fut majd le, de a processzek
|
|
adatszegmensét sokkal magasabbra állitja, ami talán elég lesz a
|
|
lekérdezés végrehajtásához. Ez az utasítás a jelenlegi processzre (a
|
|
shelled) érvényes, és minden általa létrehozott processzre. Ha
|
|
problémád van az SQL klienssel, mert a szerver túl nagy adatot küld
|
|
vissza, próbáld meg e klienssel is ugyanezt. 4.19) Hogyan tudhatom meg
|
|
PostgreSQL, milyen verziót futtatok? A psql programban select
|
|
version(); 4.20) Miért kapok "invalid large obj descriptor" hibát nagy
|
|
objektumok kezelésénél? A nagy objektumok kezelését egy tranzakciós
|
|
blokkban helyezd el. (BEGIN és COMMIT között) Jelenleg a PostgreSQL
|
|
ezt a szabályt azzal teszi kötelezővé, hogy a tranzakció végén a nagy
|
|
objektumokat lezárja, igy a tranzakció után az első művelet amit az
|
|
objektumon végrahajtanál hibás lesz. Ha olyan programozási felületet
|
|
használsz mint az ODBC vagy a JDBC akkor valószinűleg ki kell
|
|
kapcsolnod az auto-commit-ot. 4.21) Hogy hozhatok létre olyan
|
|
oszlopot, aminek alapértelmezett érétke a jelenlegi idő? Használd a
|
|
CURRENT_TIMESTAMP -ot: CREATE TABLE test (x int, modtime timestamp
|
|
DEFAULT CURRENT_TIMESTAMP ); 4.22) Miért olyan lassúak az
|
|
al-lekérdezéseim IN-nel? Jelenleg az al-lekérdezéseket a külső
|
|
lekérdezéshez csatoljuk. Ha az allekérdezés csak kevés sort eredményez
|
|
és a külső lekérdezés sokat, akkor az IN is gyors. Az EXISTS kulcsszó
|
|
használatával gyorsithatod a lekérdezéseket. SELECT * FROM tab WHERE
|
|
col IN (SELECT subcol FROM subtab); EXISTS használatával: SELECT *
|
|
FROM tab WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col);
|
|
Ahhoz hogy ez gyorsan fusson le, a subcol indexelt oszlopnak kell hogy
|
|
legyen. Reméljük ezt a korlátot sikerül hamarosan legyőznünk. 4.23)
|
|
Hogyan tudok outer join-t végrehajtani? A PostgreSQL a szabványos SQL
|
|
szintaktikát követi. Itt van két példa: SELECT * FROM t1 LEFT OUTER
|
|
JOIN t2 ON (t1.col = t2.col); vagy SELECT * FROM t1 LEFT OUTER JOIN t2
|
|
USING (col); Ezek az identikus lekérdezések összekapcsolják a t1.col
|
|
és a t2.col mezőket, és a t1 bármelyik kapcsolatlan sorát is
|
|
visszadják. A RIGHT JOIN a t2 kapcsolatlan sorait adta volna vissza, a
|
|
FULL JOIN pedig a kapcsolt, és mindkét tábla kapcsolatlan sorait adja.
|
|
Az OUTER kulcsszó opcionális, a LEFT, RIGHT és FULL JOIN
|
|
szintaktikailag helyes. Az átlagos összekapcsolásokat INNER JOIN-nak
|
|
nevezzük. Az előző kiadásokban a OUTER JOIN lekérdezéseket UNION és
|
|
NOT IN kulcsszavakkal lehetett szimulálni. Például a tab1 és a tab2
|
|
összekapcsolása: SELECT tab1.col1, tab2.col2 FROM tab1, tab2 WHERE
|
|
tab1.col1 = tab2.col1 UNION ALL SELECT tab1.col1, NULL FROM tab1 WHERE
|
|
tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2) ORDER BY col1 4.24)
|
|
Hogyan tudok több adatbázison végrehajtani lekérdezést? Arra nincs
|
|
lehetőség, hogy más adatbázisból kérdezz le adatot. Mivel a PostgreSQL
|
|
adatbázis specifikus rendszer táblákat tölt be, bizonytalan hogy egy
|
|
adatbázisok közötti lekérdezésnek hogyan kellene viselkednie. A
|
|
contrib/dblink könyvtárban találsz egy megoldást erre, ami funkció
|
|
hivások segitségével működik. Persze, a kliens hozhat létre szimultán
|
|
kapcsolatot több adatbázissal, és összefésülheti az eredményeket.
|
|
4.25) Hogy tudok több soros vagy oszlopos eredményt visszaadni egy
|
|
funkcióból? A PL/pgSQL tárolt eljárás nyelvvel refcursor
|
|
használatával. Részletesen itt:
|
|
http://www.PostgreSQL.org/idocs/index.php?plpgsql-cursors.html 4.26)
|
|
Miért nem tudom megbizhatóan létrehozni és törölni az átmeneti
|
|
táblákat a PL/pgSQL funkciókban? A PL/pgSQL cacheli a funkciók
|
|
tartalmát, aminek az a szerencsétlen mellékhatása, hogy ha egy
|
|
PL/pgSQL funkció használ egy átmeneti táblát, ami kés?bb törlődik majd
|
|
ujra létrejön, akkor az újra lefutó funkció nem fogja megtalálni a
|
|
táblát, mert a cache változat a régi táblára tartalmaz mutatót. A
|
|
megoldás erre az EXECUTE utasítás használata az átmeneti táblák
|
|
kezelésére PL/pgSQL-ben. Ez a lekérdezés újrafordítását fogja
|
|
előidézni minden alkalommal. 4.27) Milyen replikációs lehetőségek
|
|
vannak? Számos master/slave replikációs lehetőség létezik. Ez csak a
|
|
master adatbázis számára teszi lehetővé, hogy az adatokat változtassa.
|
|
Egy Listát olvashatsz ezekről itt:
|
|
http://gborg.PostgreSQL.org/genpage?replication_research Egy
|
|
többfelhasználós replikációs rendszer készül itt:
|
|
http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php.
|
|
4.28) Milyen kódolási lehetőségek vannak? - A contrib/pgcrypto
|
|
tartlamaz számos SQL lekérdezésben használható kódolást. - A
|
|
kliens-szerver kommunikáció rejtjelezésére a hostssl használható. Ezt
|
|
a pg_hba.conf-ben engedélyeztheted. - Az adatbázis felhsználók
|
|
jelszavait tároláskor kódolja a rendszer. Régebbi verziókban a
|
|
PASSWORD_ENCRYPTION opcióval lehetett bekapcsolni. - A szerveren
|
|
használhatsz kódolt fájrendszert.
|
|
_________________________________________________________________ A
|
|
PostgreSQL kiterjesztése 5.1) Írtam egy felhasználói funkciót. Miért
|
|
core dumpol az adatbázis amikor használom? Számos probléma lehet.
|
|
Elöbb probáld ki a funkciódat egy különálló alkalmazásban. 5.2) Hogyan
|
|
lehet új adattípusokat és funkciókat hozzáadni a PostgreSQL
|
|
disztribúcióhoz? Küldd el a kiegészítéseid a pgsql-hackers levelezési
|
|
listára és a forráskodjaid végül a contrib-ban kötnek ki. 5.3) Hogyan
|
|
lehet olyan C funkciót írni, ami Tuple-t ad vissza? A 7.3 verziótól
|
|
kezdve a PostgreSQL támogatja a táblázatokat viszzaadó funkciókat C,
|
|
PL/pgSQL és SQL nyelveken. Bővebb dokumentációt a Programozó
|
|
kézikönyvben találsz. Egy C példa funkció található a
|
|
contrib/tablefunc könyvtárban. 5.4) Megváltoztattam egy forrás
|
|
állományt. Miért nem változik a bináris újrafordítás után? A
|
|
Makefile-ok nem ismerik a include állományok megfelelő függőségeit.
|
|
Végre kell hajtanod egy make clean-t, majd újra egy make-t. Ha GCC-t
|
|
használsz felhasználhatod a configure script --enable-depend opcióját,
|
|
így a compiler maga fogja ellenőrizni a függőségeket.
|