9i RAC-ban a redo logoknál nem csak a group meg a member változik, hanem a thread is. Minden instance-nak saját redo thread-je van. Minden instance saját magának archivál, a többiekét nem bántja. Így minden instance-nak a redo és az archlog lokálisan keletkezik. Ezért is érdekes munka pl. egy szép nagy helyreállítás...
Ezzel nincs is semmi bajom: csak fejlődjünk-fejlődjünk :)
Hogy nem kerestél elég pontosan: inkább azt mondanám, hogy én nem neveztem meg a featuret pontosan.
A "Tablespace compression" kifejezéssel csak annyi a bajom, hogy nem az jut eszembe róla, amit csinál. A "Data segment compressionnál" is azért nem jutott eszembe a pontos kifejezés, mert ez a tömörítés dolog az Oracle-nél blokkszintű. Ennek megvannak az előnyei és a hátrányai. Pl. a DB2-es tömörítés 1 db 75-100KB-os directory-t (vagy mi a neve) használ az egész táblára, ezért ott tényleg táblaszintű. Ennek köszönheti, hogy sok, az egész táblára kiterjedő érték esetén jobban tömörít, mint az Oracle, mivel nem kell minden blokkban megismételnie ezeket az értékeket. Viszont minden blokkba insertálás egy 75-100KB-os dictionaryben való túrkálást eredményez, ami mindenképp lassabb, mint egy max néhány KB-os dictionaryben való túrkálás. Ráadásul, ha a rekordok valamiért úgy helyezkednek el, hogy azonos értékek jól egymás mellett legyenek (egy blokkban), akkor akár relatív sok különböző érték is jól tömörítve tárolható az oracle-féle megoldásban. Az más kérdés, hogy erre ügyelni kell. Annyi ilyen feature van már, hogy örülök, ha a dolog lényege eszembe jut, nemhogy a marketing neve. :-) Főleg, ha folyamatosan változtatják, mimnt pl. a HTMLDB-ét :)
A DB2-őt én sem ismerem nagyon, csak a tömörítgetés kapcsán találtam rá egy ezzel kapcsolatos fórumra. A TPC-H (?) adatbázisán pedig mindkét cég publikált már tömörítési arányokat, és a DB2 magasan vezet. Mindazonáltal nekem úgy tűnik a leírásokból, hogy a dictionary-t csak reorgnál tartja karban, tehát az új értékeket nem fogja tudni tömöríteni. Persze erről nincs explicit infóm, úgyhogy akár téves is lehet a következtetésem. Ebből is látszik, hogy a szkepticizmus mindig rulez ilyen marketingszagú dolgoknál. ;-)
Na éhenhalni én sem akarok. ;-) Csak egy reorg miatt szükségem volt a compressre, az üzlet meg örült neki nagyon, hogy most akkor nem kell diszket venni. Csak közben 1 hónap alatt már 100GB-ot vesztettünk a megnyert TB-ból :( Félreértés ne essék, én tudtam, hogy fogunk veszíteni, meg nem is ígértünk hosszútávra ekkora nyereséget, csak ráharaptak :) Ezért keresek minnél tisztább, és a feldolgozás összidejét nem növelő megoldást a compress előnyeinek megőrzésére.
Nálunk az OLTP-ben is szép nagyok a history táblák, ott is szívesen kipróbálnám az 1-2 hónapnál régebbi adatokra a compresst, ha már partíciónként is lehet tömöríteni.
OTP-nél speciel két menetben is dolgoztam, az adattárház-projekten épp nem, viszont párhuzamosan más cégnél olyanokkal együtt akik rajta voltak kisebb-nagyobb mértékben igen, azaz voltak bőven infóim is. Minden szempontból tanulságos projekt...
Tetszik a hozzászólásod, de pár dolgot másképp látok.
Szerintem igazságtalan minden szoftverfejlesztőt általánosságban 'megvádolni', hogy bétát dob piacra. Például épp az emlegetett IBM DB2 szerintem ebből a szempontból nagyságrenddel rokonszenvesebb nekem. Azonkívül béta és béta között is van különbség. Az RDBMS-ek is egyre gyalázatosabb minőségben jönnek ki Oracle-nél fő verziókat tekintve, lásd 8.0, vagy 9ir1-et, de még ezek is istenesek szerintem az OWB korai verziókhoz képest.
Én úgy láttam, hogy a konzulensek mindenhez hozzáfértek (nem kellett pluszba kérdezniük), de a projektvezetőjük mindenféleképpen hozzáfért. De érdemes összevetni a hivatalos mezei halandóknak szánt amúgy brutális árvonzatú OWB-jegyzetet a belső továbbképzések anyagaival. Ugye nem kell elzongoráznom a különbséget?
Azt a lényegi koncepcionális felvetésemet továbbra is tartom, hogy az OWB egy behatárolt tudású eszköz, nem a használatán/nemhasználatán múlik egy Oracle adattárház-projekt sikere (majdhogynem tök invariáns). Sőt azt a szemtelenséget is állítom, hogy a korai OWB-verzióknál, az OWB-s projektekből az Oracle Corp. húzta a legnagyobb profitot, az ügyfelei pénzén, tisztességtelen eszközökkel.
A repository technológiának vannak előnyei, lásd például Oracle SCM, selectálni tudni forráskód verziók között, ami azért lássuk be nem kicsit finom dolog... :o) OWB-nél is voltak hasznos feature-jei, nem tagadom. Lehet az a baj, hogy túl sok csúnya bugba futottam már bele.
A Clementine érdekes kérdés. Nem tudom mit értesz új verzió alatt. Emlékeim szerint a 8-as körül vette meg az SPSS, és bár nagy innovációval vetette bele magát a fejlesztésbe, túl gyorsan, túl instabil verziókat hozott ki, ráadásul igen kevéssé tudja kezelni az SPSS-sel való amúgy tényleg baromi nehéz integrációt. A legstabilabb verzió tudtommal a 7.1, 7.2, ami már nem xwin32-es volt. Tudtommal jó pár Clementine-s guru maradt meg annál, mert a magyarországi feladatokra tökéletesen elegendőnek bizonyultak. Számomra az eredeti Clementine a jóldokumentált zseniálisan felhasználóbarát szoftver mintapéldája volt, amikor megismertem. Igaz ahogy mostanság jobban beleásom magam adatbányász projektekbe ez a kép árnyalódott egy kicsit, de ez innentől ez már offtopic a threadben.
Hogy ne legyek igazságtalan következzenek az OWB-előnyök: - Sokan használják, szabványos; kvázi cserekompatibilisen lehet fejlesztőt találni. - Egy Informatica-modul árához képest tényleg elenyésző az ára. - A scriptelési lehetőség ahogy írtam is, szimpatikus - Az Oracle nem viccel, amikor azt mondja stratégiai terméke, efelöl semmi kétségem. - Elvben tudhatna jól együttműködni az OWF-fel, Designerrel. Más kérdés, hogy ebben is sok rossz tapasztalatom halmozódott fel az idők folyamán. - Az Oracle jó platform adattárházra, kézenfekvő alternatíva az OWB - Ha rendesen fog tudni terjedni a használatának kultúrája, mint az RDBMS-nek, akkor lehet, hogy tényleg luxus lesz rá fújni. - Elfogadom a tényt, hogy létezhet projekt, ahol nélkülözhetetlen... - Tényleg tanulságos egy OWB-mapping tanulmányozása...
Sejtettem, hogy te is szívtál nagyokat, csak nem az Otp-nél voltál ? :-)
Néhány gondolatféleség : - Az Oracle, ugyanúgy mint a többi cég( gondoljunk csak a windows pistára) gyakorlatilag majdnem minden új cuccosát szinte béta állapotban hozza ki, és majd az első pár project után kiadásra kerülő verzió már jobb lesz. - amikor utoljára jártam az oracle felé, akkor csak bizonyos alkalmazottak kaptak privilegizált infoforrásokat, sima konzultáns szinte semmit, na jó azért a belső levlistákat érdemes volt olvasgatni. :-) 1ébként sokszor az zavart, hogy az OWB-t valami olyaminek képzelték el, hogy 2 gombnyomás után kiköp magából egy komplett adattárházat, tokkal-vonóval és amikor rájöttek hogy érteni is kéne hozzá, akkor voltak a gondok. Az OWB pld. remekül scriptelhető, némi tervezés után rengeteg map-et lehet elkészíteni pár perc alatt. - a repository technológiát én még nem dobnám ki az ablakon, szvsz megvan annak is a helye. - üzemeltetésre írt az ember pár servletet, oszt hali, az eredetinél szinte bármi jobb volt. - na . a Clementine nekem jó példa az átláthatóság, stabilitás stb. terén, nekem sok rossz tapasztalatom volt vele, igaz még régebbi verziókkal.
Most hogy így belegondoltam, nekem sem a kedvenc fejlesztőeszközöm, főleg a stabilitási és memóriahasználati problémái miatt. De utálni, az szvsz luxus. :-)
Én követtem el az alapvető hibát, nem elég precizen kerestem a gugliban (korábban). Azt azonban azért érdemes látni, hogy egy-egy - pláne jó - oracle feature bőven tud fejlődni az évek során, egyre több limit tűnik el, tolódik kijjebb, kerül bele újabb funkcionalitás. Lásd particionálás, materialized view, rac és sorolhatnám. Azt gondolom a "tablespace compression" is ez a kategória, talán. Néha érdemes lehet fejlődésében is nézni a dolgot, legalább hozzászólás szintjén... ;)
Amúgy az általad leírtakat nemkevés szkepticizmussal olvastam: de kívánom tiszta szívből, hogy ne legyen igazam... Minden tiszteletem a DB2 iránt, de azt gondolom távolról sincs pariban az Oracle RDBMS-sel. Az Oracle-nek évtizedek óta "csak" annyi a célja, hogy fontos kérdésekben az élbolyban legyen, és _összességében_ legyen jobb versenytársainál.
Egy ilyen tömörítősdinek nemcsak előnye/haszna van, hanem adminisztrációs, performancia és egyéb költsége is. Én bizony megkérdőjelezem az értelmességét az insertenkénti tömörítés hatékonyságának és értelmének (DW-knél nagyságrendekkel ksiebb tárigényű OLTP esetben). Azt gondolom nem az a cél, hogy labor körülmények között sikerüljön valami nagyot mutatni, hanem életszerű körülmények között valós megfogható haszon legyen a végeredmény az 'erölködésnek'.
Lehet napi 24 órai munkával 10 forint hasznot felmutatni, kérdés mennyiben tekintjük ezt nyereségnek, az éhenhalással párhuzamosan... ;)
szerintem te értesz félre valamit nagyon, a redo log sem instance-hoz tartozik. hány db redo logod van? instance-onként x db? nem, a redo log egy adott adatbázishoz tartozik és kötelező is a közös diskrendszeren tárolni.
előre megkövetlek, ha én mondom a botorságot, de hogy érted, hogy az archive logok az instance-hoz tartoznak? szerintem pedig az adatbázishoz tartoznak, globál, az, hogy hova, milyen formátumban mented az archive logokat, az is egy adatbázisparaméter, és pl. 4 clusternode-on nem négyfelé menti őket, kivéve akkor, ha direkt multiplikálva, több helyre archiválsz (tehát nem a közös diskterületre). erről van szó nálatok? egyáltalán milyen módszerrel, eszközzel mentesz?
mire gondolsz? így hirtelen hajnalban szerintem pont ugyanúgy kell archive logolni, meg azokat menteni is racon meg single instance-on. nálunk legalábbis nem merült fel különbség.
Nem szeretem a Tablespace Compression kifejezést, mivel arra utal, hogy valami táblatér szintű dologról van szó - miközben az Oracle még a táblán belül is blockonként dönti el, hogy az adott blokkra alkalmazzon-e "compression"-t, vagy sem. A tablespace-re adott compress opció csak egy default érték, amit simán felül lehet bírálni create table-nél vagy move-nál egy nocompress-szel. Az indexnél alkalmazott key compression-nek pedig nem sok köze a táblánál alkalmazott compression-höz. És nem jutott eszembe a "data segment compression", ezért írtam, hogy "datablock compression".
11g-ben az egyik new feature, hogy a data segment compression használható lesz OLTP rendszerben is! Ez minimum 2 dolgot kell jelentsen: - sima insertnél is megy a compress - nem degradálja az update sebességét annyira, mint most 9i2-ben (1/3-1/5 sebességet mértünk teszteknél). Gondolom erre azért van szükség, mert a DB2 Viper-ben a compression már most is használható általános esetben, ráadásul több esetben 2x olyan jól tömörít, mint az Oracle (azonos adaton).
Köszi a tanácsot. Kérdés, hogy hogyan lehet megvalósítani a táblafüggvényeket, hogy közben a teljesítmény ne csökkenjen a forall-os verzióhoz képest. Lehet kombinálni a két dolgot?
>Így x év Warehouse Builder használat után érteni vélem, hogy utálod. De a 10gR2-es verziót is ?
Nézd, senki nem mondta, hogy nem fejlődött az évek során és nem lett egyre jobb a termék. Azt is tudnod kell, hogy már lassan 1 éve kiestem OWB-s témákból, a 10gr2-es verziót nem is láttam még konkréten.
Az OWB-utálatomnak vannak objektív tényalapú vonzatai és vitatható szubjektív vonzatai (->hiába ajánlasz nekem egy neked szép nőt, ha nekem ronda, nem fogsz tudni rádumálni... ;).
Ami a ténybeli dolgokat ileti: - Az Oracle vérlázítóan aljas módon félig se kidolgozott koncepciók alapján extra bugos verziókat hozott ki az elején, nemegyszer. Azért minősítem aljasnak az eljárását, mert a megtévesztett vásárlókkal finanszíroztatta meg saját termékének fejlesztését. Én láttam, ahogyan a hivatalos Oracle-s OWB-ben fejlesztő konzultások vért p*sálnak a fejlesztéssel. Nekem senki ne mondja, hogy egy account profile (számlaszintű aggregáció) kilenc emberhónapnyi munkát igényel normális termékkel, nem mondom meg mikori és mennyi tízmillióért. - Nagyon komoly tudásbeli különbség volt - gyárilag előre beprogramozva? - egy hivatalos Oracle-s OWB-s között és amit földi halandó maga elérhetett -> és ezt objektív infók alapján mondom! Őket hihetetlen mennyiségű megfizethetetlen belső infók támogatták (a fentiekből kifolyólag is). Szubjektíve nekem sz*r érzés volt _bizonyítva_ látni mennyire kevés lehetek a teljes bugelhárításos OWB-s fejlesztési ciklushoz _perspektivikusan_ is!! - A repository-technológia miatti különféle verzió-migrációkról ne is beszéljünk; iszonyú költségeket jelentettek mindig is, sokszor értelmetlenül, és megmagyarázhatatlanul. - Hardver-igényben az indokoltnál nagyobb overheadet jelentett az OWB-s alkalmazás a kézzelírotthoz képest.
Ami a szubjektív részt illeti. Én azt gondolom, hogy - A repository-technológia (designer, discoverer, owb stb.), alapvetően elhibázott koncepció. Ráadásul extra mennyiségű bugot bírt általa produkálni az Oracle. - Míg a fejlesztői igényeket mindig is jobban támogatta az OWB, az üzemeltetési/ monitorozási támogatás az én ízlésem szerint sokkal gyatrább volt. Komoly hackeléseket igényelt mindig is a téma. - Valami elképesztően trágya debugolhatatlan kódot generál az OWB. Már amikor lefordul ugye, mert volt olyan, hogy bug miatt lefordíthatatlan kódot generált. Lássuk be generált kódba visszatérően kézzel belenyúlni, nem túl gusztusos mutatvány. - Azt gondolom annak a fajta vizualitásnak amit az OWB nyújt nincs sok teteje. Félreértések elkerülése végett, van amikor szerintem is létfontosságú a vizualitás, például egy adatbányász streaming manipulálásakor (Clementine, SAS), de amikor százas nagyságrendű attributumot kell egybelátni mappingek sorozatán át, ott hatékonyabb lehet a nonvisual eszközkészlet. Tudom, kiterjedten lehet programozni is az OWB-repot: mégis ahogy én a OWB-konzultásokat elnéztem ezt igen kevéssé tették mindig is. - Egy ilyen eszköznek wing-to-wing folyamat egyetlen eszközének kell lennie, amibe a tudást nem-technikai üzleti emberek is bele tudják vinni (pl.: vállalati adatszótár). Az OWB tudtommal ezt még most se produkálja szemben a BO-val/SAS-sal/Terratec-kel és a többiekkel.
Összefoglalva, azt gondolom adattárházat építeni nagyon jó dolog, például mert nagy profitot lehet belöle kisajtolni. Nagyon drága mulatság is lehet mind a felépítése, mind az elbaltázása az évek során. Azt gondolom lehet jól és jó adattárházat építeni, de meg kell hozzá találni az optimális tervezési és üzemeltetési folyamatokat amik sokkal lényegesebb kérdések mint az OWN/non-OWB kérdéskör. Az számomra nem kérdés, hogy a multinacionális Oracle az OWB-vel a saját marketing érdekeit sokkal előrébb helyezte ügyfelei érdekénél, ráadásul éveken át. Életem egy fontos szakaszára ez maradéktalanul rányomta bélyegét, ezért sose fogom szeretni az OWB-t. Nem azt mondom, hogy rossz termék (bár csak néhány belém beégett rossz tapasztalatot írtam le). Csak azt mondom, hogy utálom.
Próbálkozz a Group By parancs Rollup és Cube kiterjesztésével, ezek pont arra ez esetre vannak kitalálva, ha a lekérdezésbe összegző sorokat is szeretnél. Nem biztos, hogy pont olyan formában, ahogy szeretnéd, de megnézni érdemes.
Nem az ilyesmit szokás a kliensoldali programban megoldani? Vagy, ha például a végfelhasználó Sql*Plus-t használ, akkor Pl/Sql eljárást lehetne használni...
es megis, mire osszesitenel es hogyan? peldaul: select sum(osszeg),to_char('YYYYMMDD',datum) as datum from tabla group by to_char('YYYYMMDD',datum) ? Ami mondjuk osszesiti napok alapjan az osszeget. Talan ha leirnad mit is szeretnel, de ugy, hogy tudod mi nem tudjuk neked mi van a fejedbe ;)
Van egy lassú selectem, ami lehoz egy táblát - dátum, azonosító, összeg
szeretnék ebbe dátum szerinit összesítő sort beszúrni, majd egy teljes összesítést is elkerülve azt, hogy újra le kelljen kérdezni, vagy el kelljen tárolni a select eredményét
"Datablock compression" tényleg nincs, de Data Block Compression van. Sőt, Data Segment Compression is, ami ugyanaz. Tényleg emlegetik Tablespace Compression néven is, bár lehet tábla szinten is használni.
Az append hint említese nem tévedés. A tömörítés tényleges feltétele a direct path betöltő művelet használata, ami lehet SQL*Loader direct módban vagy insert /* +APPEND */. Mindkét esetben a lényeg, hogy nem a blokkok belsejében keresgélünk szabad helyeket, hanm a HWM fölé írunk teljes formázott blokkokat.
A konkrét kérdésre az én tanácsom: Ha tényleg kell a PL/SQL a transzformációkhoz, akkor írd meg az eljárásokat táblafüggvényként. Ha ez megvan, akkor a töltés már mehet insert append módban, kompresszió-kompatibilisen.
Sziasztok, még egy szép anomáliát értem meg, a "*"-gal. 3 szintű rendszer volt speciális snapshotokkal, triggerekkel. Egy "Worldwide" szerver, regiónális szerverek "around World", és a felhasználók saját notebookja, Oracle lite-tal. Elvileg a local gépen páros, a konszolidált adat páratlan kucsú volt, és rögzíthették délamerikában az európai adatatot. A notebook két üzemmódban működött, halózatnélkül saját db-vel, vagy a cégben dockstation-ban, a regiónális szerverrel. Amásdikesetben a háttérben megkezdődött a 2 db szinkronja. Illetve regiók folyamotosan szinkronizáltak a Központon keresztül. A sziknronizálókban volt select *. A folyamatos db definiciós változások is meg voltak oldva, csak egy bibi volt. Ha egy új reginális szervert beállítottak, mert pl Újzéland levállt Ausztráliáról, a legfrisseb db sémát gyurták bele. A mezők mind meg voltak, csak a sorrend nem stimmelt. A kolléga szépen logikai rendbe rendezte designerrel a táblákat, és nem felelt meg alter add.., alter drop rendeknek. Tehát a predefinit inerfészeket jobb kultiválni. Ha sok vele a munka a fejlesztésnél, akkor is. Édesviz
>>>>>>>>>>>>> Ha ennek a táblának a szerkezetét egy mezővel bővítjük, akkor elvileg az összes rá mutató hivatkozást is módosítani kell; ami alól szerintem csak egy olyan trigger használata mentesíthet, amely az adattáblára hivatkozásokat figyeli, és szintaktikailag hibás hivatkozások paramétereit átadja egy szintaktikailag helyes hivatkozásnak és a hiányzó paramétereknek NULL értéket ad. Ez a trigger csak akkor adna vissza hibaüzenetet, ha egy olyan adat hiányzik, amelynek nem lehet NULL értéket adni. >>>>>>>>>>>>>
Ez szerintem több szempontból sem működőképes: mit csinálsz például a plsql eljárásokban lévő stringből összerakott dinamikus sql-ekkel? Azaz nem elég a szintaktikus "garancia" kellhet a szemantikus jóság garantálása is.
Szerintem nagy rendszernél általános esetben nem egy automatikus trigger a jó megoldás, noha készséggel elismerem speciális 'redukált' esetben egy jó támogató rutint lehet írni e célból...
Hanem inkább:
- dokumentálás (esetleg előzetes tervezéssel ;).
- ha nem áll rendelkezésre az előbbi (pl.: megbízhatóan, jó minőségben, up-to-date-n), akkor sokat segíthet egy okos és következetes kódolási konvenció, a könnyű kereshetőséget támogatandó.
- Zárógondolat: megnézném magamnak azt az üzemeltetést, ahol egy ilyen automatikus triggert átvennének üzemeltetésre és nyugodtan tudnának felöle aludni... ;)
>amikor megnyugodva jelenthettük, mint fejlesztők, hogy egyetlen társunk se esett avészes rövidítés bűnébe.
Nem tudom pontosan ekörül forog-e a thread, de szerintem
- pl.: insert (select)-eknél a kötött definiált mezőlista melegen ajánlott... Az meg nézőpont kérdése, hogy mi a jobb, ha működnek a feldolgozási folymatok a háttérben a maguk rugalmasságában (és a változásokról a feldolgozás során akár nem is értesülünk), avagy jöjjenek kőkeményen a hibaüzenetek - dagadtra hízó naplók formájában -, akár egyetlen új oszlop hozzáadásakor is, mert hiszen az valamiféle potenciális anomáliát jelent.
- Ha rendszerek közti (és nem rendszeren belüli, hisz az speciális egyszerűbb eset) az ilyen típusú feldolgozás, akkor én a felelősségmegosztásban gondolkodás híve vagyok. Az 'exporter' is tudja pontosan mit ad, az 'importer' is tudja pontosan mit vesz át. És ezen 'interface' mögött mindenki tudja a saját rendszer-bizniszét csinálni, akár az OO-paradigma jegyében is.
Visszakérdezek... Jogosultság-kiadásnál nem ugyanez a helyzet? Ha A usernek oda akarom adni B user tábláinak olvasási jogát, akkor a jogosultságadás pillanata után keletkezett újabb B sémás táblákat szintén nem fogja látni A user külön explicit grant nélkül. Nézőpont kérdése, hogy helyes-e ez a filozófia, én (is) biztosan berzenkedem tőle.... ;)
