autonom transaction bug case clob xml olvasás exception message export/import function based index hierarchikus query hostnév lekérdezése job magyar sorrend

materializált view objektum típus pl/sql rank() használat séma és tábla méretek séma kötődés SQL optimalizálás SQL végrehajtási idő tablespace táblastruktúra select toad

• Ezzel a módszerrel egy teljesen különálló tranzakciót csinálunk, melyben lehet commit-álni vagy rollback-elni,
  és ez nem fog kihatni az eljárást hívó tranzakcióra.
• Például, a hívó eljárás töröl egy táblából, de a törlést visszavonja egy rollback-kel, ennek ellenére a MY_LOG_TABLE bejegyzése mégis megmarad ! Az autonom transaction résznek egy külön procedure/function-nek kell lennie,
  a fejrészben szükséges a pragma autonomous_transaction,
  és mindenképp legyen a végén egy commit (vagy rollback):

• Pl/sql clob bug:
  Ha egy pl/sql blokkban egy clob típusú változóval túl sok műveletet végzünk, akkor a blokk end-nél nem kapjuk vissza a vezérlést, mivel az oracle képtelen a clob által hátrahagyott szemetet kitakarítani.
  Megoldás: egy blokkban minél kevesebb clob-műveletet végezni, és így gyakrabban ráfutni a blokk end-re, hogy a szemét takarítás kisebb legyen, melyet az oracle így el tud végezni.

• Az sql parancson belüli case szerkezettel tetszőleges kifejezéseket megfogalmazhatók.
  Az első igaz when-ág érvényesül, ha egyik sem igaz akkor az else-ág. Ha else-ág sincs akkor null-t kapunk.
• 1. forma: a kifejezés a case után van, és a when-ágakban azt írjuk le amikor a kifejezés egyenlő valamivel:
• 2. forma: a case után nincs kifejezés, csak a when ág tartalmazza őket:

• Ha egy CLOB típusú mezőben XML van (blob-ra nem működik), akkor az XPATH segítségével ki lehet belőle nyerni adatot, például:

• PL/SQL blokk futásakor ha a hibaszöveghez hozzá akarunk férni, akkor nem elég az sqlerrm, mert csak a hiba szövegét tartalmazza, a hiba sorát nem.
  Ha a teljes hibaszöveget, és a hibasort is szeretnénk, akkor a dbms_utility.format_error... használata szükséges, például:

• Az exp/imp utility-nek összhangban kell lenni az adatbázis verziójával, különben a művelet sikertelen lesz.
  Ebben az esetben az oracle kliens exp/imp helyett az adatbázis szerveren lévő exp/imp utility-t kell használni.
• Importálás előtt léteznie kell azoknak a sémáknak melyekbe importálunk.
• Exportálás példa, ahol egy exp-parameters.txt fájl írja le az export jellemzőit.
  A példában a xesj és xesj2 schema objektumai exportálódnak, a log egy fájlba íródik: Használat:
• Exportálás példa, ahol csak egy táblát exportálunk:
  
• Importálás példa, ahol egy imp-parameters.txt fájl írja le az import jellemzőit.
  A példában a teljes export állományt importáljuk (FULL=y), a log egy fájlba íródik. Használat:
• Import esetén, ha nem a teljes állományt akarjuk importálni, akkor a FROMUSER/TOUSER-t használjuk a FULL helyett.
  Az is megoldható hogy egy exportált sémát egy másik sémába importáljuk be, például:

• Arra jó hogy segítse az olyan lekérdezést amiben az oszopokat nem tisztán, hanem átalakítva használjuk, de ez az átalakított érték pont szerepel az indexben. Például: esetén képes használni az alábbi function based index-et:

• Tegyük fel van egy LMZ_KATEG tábla ahol a KATID mező primary key, és a PARENT_KATID hivatkozik a szülő rekordra. Úgy szeretnénk lekérdezni hogy egy szinten belül a "cim" szerint abc-sorrend legyen. Ekkor a hierarchia így lekérdezhető:
• level: a különbőző elemek szintjeit adja vissza a legfelső az 1-es szint
• leaf: megadja hogy levél-e, vagyis őrá már nem hivatkozik senki. (0 = nem levél, 1 = levél)
• path: elérési útvonal a szülőtől kezdve.
  A példában / jellel vannak elválasztva a katid értékek tehát pl. ilyesmi lesz: /28/7/50

• A gép hostneve meghatározható SQL-select-tel:

• Adatbázis job létrehozása, mely minden héten csütörtökön fut 16:30-kor, és indít egy package-et, a végén rollback-el vagy commit-ál:
• A next_date, és az interval így állítandó be ha 15 percenkénti futást szeretnénk:
• Az Oracle a job futási időpontjainak kiszámításakorkor nem veszi figyelembe a job által indított folyamat végrehajtási idejét, tehát nem annak a végétől számítja a következő időpontot!

• Környezeti beállítástól függően lehetséges hogy az ORDER BY nem a magyar sorrendben hozza a karakteres adatokat. Erre a legjobb megoldás hogy az adatbázis kapcsolat létrehozása után (pool-ból való kivétel után), beállítjuk a magyar sorrendet:
• Az oracle jdbc driver a connection létrehozásakor beállítja ezeket az NLS értékeket, és ez függ a java Locale.setDefault() beállítástól.
  Mivel a java Locale.setDefault() beállítás nem a legjobb megoldás (konkurrensen épp átállíthatja más értékre ugyanebben a JVM-ben futó másik szál),
  ezért a fent leírt alter session megoldás a legjobb.
• Amikor nem helyes a magyar sorrend akkor az nls_sort tipikusan binary-re van állítva. A session paraméterek beállítása így tekinthető meg:

• A m.view-t elsősorban a gyors adatelérés miatt alkalmazzuk.
  Index(ek) is rakhatók rá hiszen táblaként viselkedik, az adatokat tartalmazza.
• Egy hasznos cikk
• A m.view létrehozásához szükséges jog, mely system user alól adható ki:
• Példa egy m.view létrehozására, mely azonnal létrejön, de csak manuálisan frissül az on demand beállítás miatt:
• M.view manuális frissítése:
• M.view törlése:
• Ha a m.view alatt lévő tábla/view struktúrája megváltozik (pl. oszlopszélesség), akkor a m.view nem frissíthető, el kell dobni és újra létrehozni.

• Ha az UGYFEL tábla CIM mezője objektum típusú, akkor úgy lehet belőle select-álni hogy a táblának alias-t kell adni, és ezzel kell végigírni az objektum hierarchiát:

• Http-request hívás
  
• Tömb kezelés
  

• Ez az analitikus függvény arra jó hogy egy select eredményét az order by után sorbaállítva szűrjük. Így óriási lekérdezések helyett szeleteket vágunk ki az eredményből, és csak azt a pár sort kérdezzük melyre szükségünk van, és ez felhasználható pl. lapozható eredménytáblákhoz.
• A példában a belső select kiegészíti a táblát egy rank (rk nevű) oszloppal, és a külső select-ben erre szűrünk. Így pl. a külső select variálja a where feltételt és mindig csak pár sort kérdez le a nagy adathalmazból: Az 1. lekérdezésnél: WHERE RK BETWEEN 1 AND 10
  a 2. lekérdezésnél: WHERE RK BETWEEN 11 AND 20

• A 100 legnagyobb objektum mérete az egész adatbázisban:
• Egy teljes séma mérete:
• Egy tábla (BEJELENTES) mérete:
• LOB segmensek mérete (mivel a BLOB, CLOB mezőtartalmak nem tábla szinten tárolódnak):

• Egy pl/sql procedúra ahhoz a sémához van kötve mely tartalmazza. Ha egy másik sémával vagyunk az adatbázishoz bejelentkezve, és azzal hajtjuk végre a procedurát, akkor is a kötött sémában (a séma objektumain) végződnek el a műveletek. Sőt, a bejelentkezett usernek jogának sem kell lenni arra a táblára melybe a procedúra beleír, elég a procedúrára a végrehajtási jog !

• Lassú SQL végrehajtás lehetséges abban az esetben amikor a WHERE feltételben az AND kapcsolatok keverednek OR kapcsolattal. Egy megoldás ha átírjuk az OR kapcsolatot UNION-ra, például: esetén így lehet átírni a parancsot: Egy ilyen átírás egy 500.000 soros táblából való lekérdezésnél a 100 másodperces végrehajtási időt lecsökkentette 0.2 másodpercre.

• Az SQL tárban lévő sql-parancsok végrehajtási idejének mérése. SYSTEM userrel kell futtatni:

• Az "adatlapok" tábla blob típusú "dokumentum" oszlopának áthelyezése a "big" táblatérbe:

• Egy tetszőleges tábla struktúrája SQL-SELECT segítségével kilistázva:

• Adatbázist terhelő aktív session-ök listázása:
• Ha toad-dal (sql*plus-szal) nem lehet kapcsolódni az adatbázishoz, pedig a tnsnames.ora-ból fel tudja venni az az adatbázis neveket, akkor lehetséges hogy a regedit-ből hiányzik egy bejegyzés a HKEY_LOCAL_MACHINE/software/oracle helyen például: