ORA-00932: ellentmondásos adattípusok: - helyett NCLOB szerepel

A címben leírt hibaüzenetet produkáló környezet tömören:

• IIS7
• Oracle 11g
• Entity Framework - Oracle provider Beta
  

A hibaüzenet nem mond sokat. Az történt, hogy a fejlesztői környezetben minden faszán ment, a teszt környezetben ügyfélnél jött elő ez. Alkalmazás elindulásakor, amikor böngészőben lehívunk egy oldalt (Unity resolution failed exception).
Filóztunk, hogy mi lehet más ott mint itt. Az ottani séma db scriptjéből a fejlesztőin létrehoztam egy újat, hogy lássuk séma eltérés van-e.
Nem. Itt elindult minden.
Karakterkódolás volt a következő tipp, mert amúgy minden stimmelt.
Nem az a para.
Hosszas olvasgatás után kiderült, hogy akkor dob ilyen hibát, amikor nullt kap az EF beta provider egy olyan select-nél paraméterül, amit ellenőrizve a where-ben a mező nem lehet null.
Aztán tipp volt, hogy a usert nem tudja feloldani, és az authentikáció és belépés során itt szállhat el.
Beigazolódott, az IIS-ben elmaradt az anonymus authentikáció tiltása, és null-t küldött a user nevet paraméterül megkapó sql-ben.

Feladat megoldva, de az oracle és a Beta EF provider elmehet a @@@@@ba, hogy ilyen hibaüzenetet dob.

Oracle tuning - system paraméterek

Már régóta szívok az Oracle szerverrel, nem mindig olyan explain plan-t használ mint szeretném, és rátaláltam a következő weboldalra:

http://www.dba-oracle.com/art_orafaq_tune_parms.htm

Nem a statisztika generálásról szól, az egy teljesen más téma, arról is írok hamarosan. Ez arról szól, hogy default-ként az oracle úgy van beállítva, hogy ne terheljen agyon egy szervert, és batch folyamatokra van optimalizálva.
Tehát pl ha te tudod hogy a lekérdezések 95%-a 1 sort fog visszaadni, és ehhez a full table scan-ek helyett indexeket használjon, akkor meg kell neki mondani. Súlyozni kell az indexeket, hogy a végleges cost-ban az jöjjön ki, hogy igen, indexet kell használni. Ahogy azt is meg kell mondani, hogy cache-elje az indexeket, meg még soksok trükk van. Akit érdekel, olvassa el a cikket, hasznos lehet ha oracle-el találkoztok a jövőben. Az itt található paraméterekre rákeresve a gugliban további nagyon hasznos tippekre lehet akadni. Szép játék.

Oracle-ből vissza a service-nek

Ez a bejegyzés nem olyan mint a többi megszokott, nem egy végigszopott valamit írok le, hanem megoldást keresek egy problémára, ami nem túl egyszerű.

Röviden:
Van egy oracle adatbázis, sok tábla lesz benne, amiből sokat be lehet cache-elni a service ÉS kliens oldalon egyaránt.
Feladat: a cache-eket valahogy invalidálni kellene, és kikényszeríteni, hogy ha változik alatta az adat.
A periodikus ránézegetést kerülni kellene, így is van elég baja az adatbázisnak.

Lehetséges megoldások:
Két megoldás létezik a fejekben most, egyik az oracle ún. Alert cucca, ami arra van, hogy tud szólni aszinkron valakinek bizonyos eseményekről (is), mint pl insert, update, delete. Ez egyelőre parkolópályán, mert nem erre találták ki, hanem inkább dba-knak való, hogy bizonyos eseményekről küldjön emailt. Éppen ezért alert a neve.

Másik megoldás, hogy egy after* triggerből hívunk egy job-ot, ami aszinkron, na de ennek valószínűleg egy web service-t kellene meghívni (ahogy az első megoldásnak is), amivel ki tudjuk ütni a cache-t.
Ez nem olyan nehéz, triggert írni, ami egy job-ot hív, ami egy web service-nek szól. De a bonyodalom kezdődik, mert ez egy cert-es net.tcp-s wcf service, wsse authentikációval, tehát a cert mellé kellene még küldeni folyton username jelszó párost, ezt összekonfigolni előre láthatóan sok nap szopás.

A kérdés tehát:
Tud valaki valamilyen jó megoldást arra, hogy oracle-ből hogyan szóljunk "fel" egy service-nek, hogy helló, ezt a cache-t ki kellene üríteni, és frissíteni, mert változott?

Jó megoldás jöhet balaton szeletért pl... vagy köszönömért.

Oracle Materializált View

Nem tudom ki mennyit tud a materializált VIEW-k használatáról oracle-ben, én ma hatalmas tapasztalatot szereztem ezzel kapcsolatban.
Itt egy link, ahol el lehet olvasni, hogy nagyjából mi is ez, és mire való:
http://download.oracle.com/docs/cd/B10500_01/server.920/a96567/repmview.htm

Namármost, múlt héten egy elég nagy adatbázis táblához (24 millió sor) létrehoztam egyet, hogy amikor egy migrációs cucc fut, szűkítve legyen a halmaz, amiből select-el visszaadunk rekordokat. Tökéletesen működött, a frissítési beállítás NEVER REFRESH volt, vagyis onnantól kezdve hogy létrehoztam, nem frissült a tartalma. Be volt cache-elve magyarul. Jó is volt ez így nekünk.
Ma reggel, mikor a migráció lefutott, átállítottam a frissítési stratégiát ON COMMIT-ra, ami azt jelenti, hogy minden commit esetén frissíti a tartalmat, hisz szinkronizálni kellett a migráció kezdete óta bekerült rekordokat.
Hát ezt nem kellett volna, mert a táblán másodpercenként sok insert és update van, vagyis sok commit, ami miatt folyton frissíteni próbálta a tartalmat. Megfeküdt miatta az egész adatbázis szerver. Ilyenkor nem lehet drop-olni sem, mert fogják a tranzakciók! Csak server restart-al lehetett helyrehozni. Nem vagyok büszke rá, de komoly tapasztalat...

Tehát a tanulság: meggondolatlanul ne hozzunk létre materializált VIEW-kat!

Térjünk át Oracle fejlesztésre gyorsan, MSSQL szemmel - 2. rész

2. rész, alapvető különbségek

Tegyük fel, hogy az első részt elolvastuk, és megnéztük a tutorialt, felfedeztük a webes adminisztációt. Biztos találkoztunk néhány furcsasággal.

1. Új adatbázis
MS SQL-ben azt szoktuk meg, hogy ha egy új alkalmazást fejlesztünk, vagy ki akarunk próbálni valamit, akkor erre létrehozunk egy új adatbázist. Management studio-ban a Databases-en jobbklikk, és pillanatok alatt készen van. Itt, oracle-ben kicsit mást jelent az, hogy "új adatbázis", más a fogalom. A webes adminisztrációval tudunk ilyet csinálni, de totál mást jelent. Azt jelenti hogy egy új adatbázis instance-t hozunk létre. Egy új service-ünk is lesz, ami éppúgy sok100 mega memóriát megzabál. Nem ezt szeretnénk.
Ami nekünk kell, az egy új Schema. Ez az első fogalom, amit MSSQL ismeretekkel a legnehezebb megszokni. Úgy működik az egész, hogy egy új USER-t kell létrehoznunk, ami azzal egyenértékű, hogy új SHEMA-t hozunk létre. Tehát egy Schema egy User-hez tartozik. Még egyszer, példával. Ha van egy raktár programunk, meg egy webshop-unk, akkor MSSQL-ben létrehozunk egy WMS adatbázist, meg egy EShop adatbázist. És ehhez adogatunk hozzá SQL usereket, adunk nekik jogosultságot, vagy domain usereket használunk, és nekik adunk jogokat. Na, itt, oracle-ben ez nem így van, felejtsük is el ilyen SQL-es emlékeinket kicsit. Itt létrehozunk egy WMS usert, schema-t, és egy EShop usert, schema-t. Ha fejlesztői szemmel nézzük, akkor semmi extra nincsen benne, ha majd az SQL developert használjuk, nagyjából hasonlóan kezeljük mind a kettőt. Kapcsolódunk a szerverhez egy connection-el (aminek a usere pl WMS), és akkor lényegében csak azokat a táblákat/eljárásokat stb. fogjuk látni, amelyek abban a sémában vannak. Pontosabban más séma objektumait is láthatjuk, ha van hozzá jogunk, pl ha SYS userrel csattanunk neki a servernek, mindent látunk! Ez a dolog tehát ne nagyon zavarjon össze minket, nem kell túlspirázni, ez így van és kész. Azt, hogy ennek a hátterében mi van, egyelőre nem kell tudnunk, kezdetnek elég ha megszokjuk.

2. Típusok (Int, Bit, Binary, VarChar)
Int:
Ha MSSQL-ben egy táblát létrehoztunk, akkor az esetek nagy többségében az első mező amit felvettünk az egy Id, ami INT. Na, hát itt olyan sincs. Ugyan némely fejlesztő eszközben ezt ki lehet választani mint opció, nem jelent semmit, ha utána megnézzük a táblánkat kiscriptelve, látjuk hogy NUMBER lett az Id. Ez egy kicsit zavaros, mert ha decimal-t akarunk tárolni, akkor az is NUMBER, a hosszával lehet variálni. Ott lesz ez majd érdekes, ha az ODP .NET providert használjuk .NET kódból, úgy kell majd, hogy ha int-et várunk, akkor az OracleDBType.Int32, ha decimal-t akkor az OracleDBType.Decimal, a tárolt eljárásban meg mindkettő NUMBER. Erről egyelőre elég most ennyi.
Bit:
Az is furcsa lehet, hogy nincs Bit típus. Nincs Boolean. Egyik sincs. Tehát ha True - False értékeket akarunk használni, akkor arra is NUMBER-t javasolnak, amiben 0 meg 1 lesz...
Binary:
Ilyen típust sem találunk. Ha bináris adatot akarunk tárolni, akkor arra a BLOB nevű mezőt kell használnunk, ez a Binary Large Object.
VarChar:
Már nem meglepő, de ilyen sincs. Helyette a VARCHAR2 típust használjuk. Ha hosszú szöveget akarunk tárolni, arra meg a CLOB való, Character Large Object. Arra kell vigyázni a VARCHAR2-nél, hogy amikor a mezőnek megadjuk hogy milyen típusú legyen, és a hosszát is beállítjuk, akkor az alapból nem a karaktert jelenti, hanem hogy BYTE-ban mekkora lehet max. Tehát ki kell választani azt is, hogy CHAR, és így a hossza karakterben értendő. A típusokról itt egy nagyon jó összefoglaló táblázat, érdemes elolvasni, mi milyen hosszú, mi mit tud. Ha MSSQL szemmel akarjuk nézni, készítettem egy megfeleltető táblázatot. Ha valaki hibát talál benne, írja meg kommentben.

3. Autogenerated Identity
Ha egy Unique Id-t akarunk létrehozni, amivel nem akarunk különösebben törődni, azt akarjuk hogy auto-generated legyen, nem triviális Oracle-ben annyira, mint MSSQL-ben. Utóbbiban megadjuk a mező definiálásakor, hogy auto-generated legyen, és ennyi. Oracle-ben nincs ilyen. Ott ún. Szekvenciát kell erre használni. Külön létre kell hozni egy szekvenciát, ami kezeli a mezőben levő NUMBER folyamatos növekedését. Létrehozás, használat. Lehet könnyíteni a használatát, BEFORE Insert Triggert létrehozni, és akkor tényleg nem is kell vele foglalkozni, csak úgy nehezebb az új Id-t visszaadni paraméterként.

4. Szintaxis
Jónéhány eltérés van a szintaxisban is. Mivel ez sok, néhány link, ahol olvashatunk ezekről, később visszatérünk rá.
http://it.toolbox.com/blogs/oracle-guide/what-is-the-difference-between-oracle-sql-and-plsql-9602

http://jopinblog.wordpress.com/2007/04/24/oracle-plsql-equivalents-for-ms-sql-server-t-sql-constructs/

Megjegyzés:
Foly köv., SQL Developer használattal

Térjünk át Oracle fejlesztésre gyorsan, MSSQL szemmel - 1. rész

1. rész, telepítés, ismerkedés

Eme blogbejegyzés azoknak szól, akiknek van már tapasztalata MSSQL fejlesztésben, és ismeretlenül, újoncként egyszer csak bele kell csöppennie az Oracle fejlesztés rejtelmeibe.
Megpróbálom pár bekezdésben összefoglalni, hogy melyek azok a tulajdonságok, amelyeket másképp szoktunk meg MSSQL fejlesztés során, és sokan meglepő arccal (én is köztük voltam) vesznek tudomásul. De no para, nincs nagy vész, idő kérdése és mindent meg lehet szokni, kicsit más szemmel kell nézni.

Ami kellene nekünk, hogy próbálgatni, fejlesztgetni tudjunk, ahhoz egy adatbázis szervert kell letölteni. Ha csatlakozni akarunk a szerverre, akkor mindenféle Client Tool-okat is fel kell tenni, tehát ilyen is kell, és kell egy eszköz, amivel fejleszteni tudunk.
Tehát egy adatbázis szervert kell leszednünk. Lassan 2 éve hogy kijött a 11G, de én próbálgatásnak simán a 10G-t ajánlom, mint release, nincs 300 mega, és elkezdeni teljesen jó. Az Express Edition-t le tudjuk tölteni innen: Oracle Database 10g Release 2 (10.2.0.1). Előtte regisztrálni kell, kicsit macera de hát ez van... Ha letöltöttük, akkor a csomag tartalmazza a client eszközöket is, telepítési útmutató róla itt. Ugyan azt írják, hogy "easy to install", nekem volt már rá példa hogy napokat szívtam, mire normálisan működésre bírtam, és használni tudtam. Amikor először csináltam, egy hétig szívtam (tűzfallal, portokkal, adminisztrációjával, de ez majd másik blogbejegyzés) mire egy tárolt eljárást tudtam hívni. Van akinek ez 3 óra alatt sikerült, nem szétkonfigolt XP-re kell feltenni :).


Szóval ha leszedtük, feltelepítettük az útmutató alapján, akkor ha minden igaz van egy Oracle server instance-unk a gépünkön, és ha jól csináltuk akkor a client cuccok is fent vannak. Ezek majd a szerverhez való csatlakozáshoz kellenek. A telepítőben van egy tool, aminek a neve Oracle SQL Developer. Ez egy ingyenes fejlesztő eszköz. Én nagyon sokat szívtam vele 2-3 éve, fapados volt és bugos. Azért, mert mindössze 4 fejlesztő barkácsolta. Azóta sokminden változott, a csomagban nem tudom melyik verzió van, érdemes a legutóbbit letölteni. Kipróbáltam, hatalmas a különbség (van intellisene, nem fagy, svn beépítve stb), jó lett.


Olyan verziót töltsünk le, amiben van JDK, a letöltő oldalon részletezve van hogy melyikben mi van. Azt is elmondom miért. Ezt az alkalmazást JAVA-ban írják, ugye pont a platform függetlenség miatt, mert ugyan az elején nem mondtam, de egy nagyon fontos dolog: maga az oracle egy platform független alkalmazás, és a hozzá való SQL Developer is. Tehát LINUX-on is fut, ezt az egyik alapvető különbségnek vehetjük (mármint az MS SQL-hez viszonyítva). Térjünk vissza oda, hogy miért olyan kell, amiben van JDK. Azért, mert ha a gépünkön más JVM van fent, akkor könnyen "fagyos" lesz a hangulatunk amikor alkalmanként érthetetlen módon meghal. Az a biztos ami hozzá való. Ezt nem nagyon kell telepíteni, csak kizippelni valahova és elindítani az exe-t.

Mielőtt az SQL developerrel foglalkoznánk, pár szó az alap admin eszközökről. A telepítés után rendelkezésünkre áll egy weboldal a local gépünkön, amin keresztül sok jóságot csinálhatunk. Kezdetnek nézzük meg ez a getting started guide-ot. Ha belépünk pl a SYS userrel (aminek a jelszavát telepítéskor adtunk meg), akkor ilyesmit kell látnunk.

Kattintgassunk, nézzük meg milyen lehetőségeink vannak. Ha ezzel megvagyunk, és kíváncsiak vagyunk hogyan hozzunk létre usereket, táblákat stb, akkor ezt a jó kis tutorial-t átböngészhetjük. Nézzük, emésszük, használjuk a webes eszközt kicsit, de ne vigyük túlzásba mert majd az SQL Developer lesz az, amivel ugyanezeket megcsinálhatjuk. Pöppet emészteni kell. Ha úgy érezzük hogy tisztult, akkor lépjünk tovább a 2. fejezetre, ott a szembetűnő különbségeket, számunkra "újdonságokat" taglaljuk.