Index of /postgresql-8.2.5/FAQ/FAQ_hungarian.html |
Utolsó módosítás dátuma: 2005 május 9.
Fordítás aktualizálása: 2005 június
A GyIK karbantartója: Bruce Momjian (pgman@candle.pha.pa.us)
Fordító: Hornyák László
(laszlo.hornyak.nospam@gmail.com)
A legfrissebb verzió itt érhetõ el (angol):
http://www.PostgreSQL.org/docs/faq-english.html.
Legfrissebb magyar nyelvû verzió:
http://hackers.forgeahead.hu/space/PostgreSQL/GYIK
Platform specifikus kérdések:
http://www.PostgreSQL.org/users-lounge/docs/faq.html.
Í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 eredeti 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.
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.
--------------------
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.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
subscribe
end
A fejlesztői levelezési lista: pgsql-hackers-request@PostgreSQL.org a következõ tartalommal:
subscribe
end
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
Magyar nyelvű levelezési lista nincs, de ha tudok segiteni a fenit e-mail cimemen elérhető vagyok.
1.7 Melyik a legfrissebb kiadás?A legfrissebb PostgreSQL kiadás a 8.0.
A tervek szerint minden évben lesz egy nagyobb
fejlesztéseket tartalmazó kiadás, míg a
kisebb fejlesztéseket néhány havonta adjuk ki.
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").
Igen, könnyedén kezeli a 2000 utáni és idõszámításunk elött 2000 elötti dátumokat is.
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.
1.16 Ki
irányítja a PostgreSQL-t?
Ha központi bizottságot, ellenörző céget keresel a PostgreSQL mögött, add fel, nincs ilyesmi. Létezik egy mag és CVS commiter csoport, de ez inkáb adminisztrativ mint ellenörző célú. A projectet fejlesztők és felhasználók közössége irányítja, amihez bárki csatlakozhat. Csupán annyit kell tenned hogy felíratkozol a levelezőlistékra és részt veszel a beszélgetésekben.
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?
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 http://techdocs.postgresql.org/guides/GUITools
oldalon találhatsz egy pontos és részltes
listát.
2.4 Milyen programozási nyelvekkel lehet elérni a PostgreSQL szervert?
A következök:
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"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étrehozni.
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.
Hardver kiválasztásában segíthet: http://candle.pha.pa.us/main/writings/pgsql/hw_performance/index.html
és http://www.powerpostgresql.com/PerfList/.
A postgresql.conf beállitásaival kapcsolatos tudnivalók: http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html és http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.
3.7) Milyen hibakeresõ lehetõségek érhetõek el?
A PostgreSQL számos lehetöséggel rendelkezik ami értékes lehet a hibakeresé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)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 helyreállitás nélkül.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;
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ányA PostgreSQL akár a szöveg állomány helyigényének ötszörösét is elfoglalhatja.
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 ezeketa 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:
Olvasd el a dokumentáció EXPLAIN-ról szóló részét.
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?
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?
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.
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:
http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glossary.html
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 col1Arra 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öltbe, bizonytalan hogy egy adatbázisok közötti lekérdezésnek hogyankellene 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étreszimultá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 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.
Bár a replikáció egyetlen terület, több technológia létezik replikációra, természetesen mindnek meg vannak a maga előnyei és hátrányai.
A master/slave replikációs megoldással a master adatbázison hajthatunk végre modosításokat, míg a slave adatbázisokon csak lekérdezéseket. A PostgreSQL legnépszerűbb master/slave replikációs megoldása a Solny-I.
Számos más master/slave replikációs lehetõség létezik.Egy Listát olvashatsz ezekrõl itt:
http://gborg.PostgreSQL.org/genpage?replication_research
A multi-master replikáció lehetővé teszi több master adatbázis használatát, bár ez a technológia drasztikusan csökkenti az adatbázis teljesítményét a sok szinkornizáció miatt. A PGCluster a legelterjedtebb ilyen megoldás.
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?
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.
HIVE: All information for read only. Please respect copyright! |
