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.... ;)
Hát ahogy a közmondás mondja, ugatós kutya legyek, ha értem a kérdést... ;)
Oracle "Datablock Compression"? Nekem egy találat sem jött ki a gugliból. Én amire gondolni tudok az a tablespace compression, ami szerintem amúgy nagy találmány. Némi plusz CPU művelet árán, átlagosan akár 50%-kal csökkenthetődnek a nagyon költséges blokk-műveletek. (Hiszen feleannyi tárfoglalás, feleannyi blokkírást és -olvasást vonhat maga után pl.: full scan esetén)
Nem tudom ki állította neked, hogy "mindenképp szükséges" plsql-kód: az én tapasztalatom szerint lehet hatékonyan pusztán sql-ben is abszolválni az ilyen dolgokat. És számtalan előnye van az átláthatóságtól, a módosíthatóságon keresztül a hatékonysági kérdésekig. És még keretrendszert is könnyű abszolválni hozzá...;) Zárójelben megjegyezném, ahogy több transzformáló sql gyorsabb lehet egyetlen plsql-es átemelésnél, úgy egyetlen jól megírt plsql-blokk is kenterbe tud verni egy sql-t végrehajtási idő vonatkozásában. Mint ahogy az én tapasztalatom az is, hogy minden eljárás majdhogynem mindig továbboptimalizálható: ahogy nincs olyan túratáska, amibe ne férne el még plusz egy kenyér, csak akarni kell... :o))
Szerintem Guinness-rekorder vagyok Oracle Warehouse Builder utálatban ;), de azt meggyőzödéssel állítom, hogy a legmagasabb szinten a legkomolyabban implementálta mindazt a tudást az Oracle e szoftverében, amit saját rdbms-ről gondol & tud. Következésképp érdemes lehet megnézni, hogy egy generált OWB plsql mapping mit és hogyan csinál. És ez talán nem egy nagy erőfeszítés, főleg, ha csak a demókat megböngészi az ember (és nem kísérel meg saját maga egyet kikínlódni)
Append hint tömörítene? Nincs itt valami keveredés? Az én tudtommal ez egy performancia hint, hogy az insert _gyorsabban_ történjen, a HWM (High Watermark) egyszerű áthelyezésével, utólagos indexépítéssel stb. Némileg hasonlóan az sqlldr direct path-os töltéséhez.
Hintekkel kapcoslatos alapszabály, hogy az sql-optimizer mindig figyelembe veszi a hintet, HA TUDJA(!!)
bulk collection-t meg forall igen hasznos plsql nyelvi eszközök. Érdemes velük foglalkozni mind statikus mind dinamikus sql esetében, szerintem is
Az én javaslatom: próbáld meg újra fogalmazni a kérdésedet, akkor könnyebben kaphatsz választ...
Datablock Compression kérdés: Hogyan lehet compress-el kompatibilissá alakítani PL/SQL processeket, amik Oracle (ajánlás szerint) bulk collection-t meg forall-t használnak nagyobb tömegű adatok ellenőrzött áttöltésére. Közben természetesen mindenféle adatösszeszedést, adatoknverziót, mappinget, adatellenőrzést hajtanak végre, tehát mindenképp szükséges a PL/SQL kód, nem lehet insert /*+append*/ select-et használni. Megpróbáltam, hogy a forall-os insertbe beírtam az append-et, de nem tömörített :( (pedig a trace-ben látszott, hogy 5000 soronként hajtott csak végre insertet és bene is volt az append, de sajnos "insert /*+ append */ into x values..." formában szerepelt, és úgy látszik, erre nem kapcsolt az SQL, hogy akár meg is csinálhatná az append-et. Elvileg 11g-ben majd ez már fog menni, de most 9.2-őn vagyunk :( Bármilyen ötletet szívesen fogadok :)
Pl. nem lehetne index nélkül hivatkozni a memőriatömbökre, mint forrásra és így kinyomni belőlük a táblába az adatokat?
A VIEW-val én is megjártam, azt hittem, tényleg az tárolódik az Oracle lelkében, hogy "SELECT *", de nem, hanem a "CREATE VIEW" pillanatában létező mezők listája... tehát ha új mező jön be, akkor a ilyen "SELECT *"-os VIEW-kat is "CREATE OR REPLACE"-olni kell.
Sziasztok, persze, hogy kontextus függő, pl egy sub select-ben exist mögött még lehetne * is, de ha simán áll egy view-ban, akkor a view is megváltozik. Nekem már volt olyan feladatom, hogy saját rendszernél, már működött vagy 3 éve, több százezer, közelítőleg milliónyi vegyes forrássorból kellett kikereseni a "select *" kifejezéseket. Az ártóakat, és nem ártóakat. Illetve volt olyan is, amikor megnyugodva jelenthettük, mint fejlesztők, hogy egyetlen társunk se esett avészes rövidítés bűnébe. Édesviz
Kontextustól függ. Pro*C-ben ilyenkor ORA-nemtudommennyi-t kapok, ha viszont egy SYSREFCURSOR-om van, amit a PL/SQL-től kaptam, és abból nem olvasok ki minden mezőt a FETCH-ben, az nem okoz gondot.
lehet a mező defaultja null, tehát az összes insert, update delete, futni fog,
csak a select * nem.
Én inkább egy párhuazmos táblát készítenék, kulcs duplikációval, és uj mezővel, mezőkkel. a trigger készítéshez pedig create or replace trigger utesítást ajánlanám
> 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
Ez azért így, generikusan nem igaz, a következő esetekkel kell törődni: 1. SELECT * 2. INSERT, ha az új mező NOT NULL 3. Amikor az új mezőt adattal kell tölteni
Adott egy olyan nagyméretű alkalmazás, amely gyakorlatilag csak részlegesen átlátható. Ez az alkalmazás egy olyan Oracle adatbázist használ, amelyben az egyik adattábláról nem lehet biztosan tudni azt, hogy az alkalmazás mely részeiről történik rá hivatkozás. Ez a hivatkozás lehet rekord beszúrás és módosítás is.
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.
Köszi szépen a segítséget! Az "INSERT INTO tábla1 SELECT * FROM tábla2" meghozta a várt eredményt. De nem tudom, hogy korábban miért nem ment, pedig próbálkoztam... Mindenesetre már 16millió rekordnál elértem az Express változat korlátját, úgyhogy... ennyit erről...
Talán épp arra "gondol," hogy egy ilyen INSERT több sort is behozhat, ezért nem használható a RETURNING... csak akkor a szintaxisgráfot is úgy kellett volna megcsinálni, hogy ne sugalljon olyasmit, amit nem lehet...
Nem lenne külön adatbázisban, csak nem tudtam, hogy kell-e ez az infó. A create table as select működik, de nekem másra van szükségem. Nem jól fogalmaztam valószínűleg. Fel szeretnék tölteni egy adatbázist 50millió rekorddal, és van már egy 2milliós táblám. Ezt a 2millió rekordot szeretném többször beemelni egy másik táblába. Foxproból egy a 2millió feltöltése is nagyon sok idő volt, az sql szerver sokkal gyorsabban megcsinálná.
Üdv! Hogyan lehet 1 tábla tartalmát átemelni egy másikba? A copy valamiért nem akar összejönni. Egy adatbázisban vannak, mivel Oracle Express-el próbálkozom.
