Jasper

ein index besteht aus einem root-block (wurzel), einer oder mehreren ebene(n) von branch-blöcken (äste) und eben den erwähnten leaf-blöcken (blätter). der root-block verweist nur auf branch-blöcke, diese wiederum auf die leafs. in den leafs stehen die indexwerte mit den zugehörigen rowids der datenblöcke. insofern kann man leaf-blocks als index-datenblöcke ansehen. -j

links habe ich keine. ist aber eigentlich recht einfach: ist einfach ein mass für die zuordnung der leaf-blöcke des index zu den datenblöcken, also wie geordnet die rows in den datenblöcken in bezug zu den leaf-blöcken sind. geht clustering factor in richtung anzahl datenblöcke, nimmt die ordnung zu, geht der factor in richtung anzahl rows, nimmt die ordnung ab. praktisch gesehen bezeichnet clustering factor die anzahl logischer I/O-operationen, die notwendig sind, die gesamte tabelle per index access zu lesen (das ist der eigentliche zweck des wertes, nämlich kosten für den CBO zu berechnen). angenommen, eine tabelle hat 1000 rows, 10 rows pro datenblock. die tabelle hat einen PK, streng monoton steigend. um jeden zeile der tabelle per pk zu lesen, müssen exakt 100 datenblöcke logisch gelesen werden, jeder block nur einmal => clustering factor = 100. falls die jeweils nächste zeile aber in einem anderen datenblock liegt (also zeile 1 in block 1, zeile 2 in block, zeile 3 in block, ..), müssen 1000 blöcke logisch gelesen werden, pro row ein block. ingesamt sind das zwar wiederum nur 100 blöcke, aber jeder block dafür 10 mal. in dem fall ist clustering factor = 1000. clustering factor kann damit nur zwischen anzahl blöcke der tabelle und anzahl der rows der tabelle liegen, je näher am ersten wert, desto besser. -j

AFAIK bleiben in AUM die segmente während der laufzeit der instanz immer online. ansonsten funktioniert flashback nicht. -j

ja, das prinzip hat sich nicht geändert. der unterschied zwischen MUM und AUM liegt nur in der verwaltung der segmente. -j

eigentlich nicht, ist ziemlich clever. stimmt, bis auf Undo-Segmente == Datenblöcke. genauso ist es. alle daten, also auch undo-daten werden durch die redo-informationen in der rollforward-phase ab dem letzten checkpoint wiederhergestellt. die anschliessende rollback-phase verwendet die wiederhergestellten undo-daten für das zurückrollen aller nicht committeten transaktionen. oracle kennt autonome transaktionen, also transaktionen innerhalb einer transaktion. rekursive sql-statements werden damit committet ohne die umgebende transaktion zu committen. das elegante an der sache ist, dass einzig und allein die redologs für ein recovery wichtig sind. angenommen, mir geht der undo-tablespace verloren, wie sollte der wiederhergestellt werden, wenn die daten direkt in den undo-tablespace (wie temp-tablespace) geschrieben werden? undo-daten sind aktive daten und müssen vor ausfall geschützt werden, dass wird perfekt durch die absicherung mit redo erledigt. -j

es fliegt eigentlich nichts aus dem undo-tablespace, wäre zu aufwändig. die blöcke werden einfach überschrieben. uncommitted undo blocks gehören nicht mehr zu aktiven transaktionen, werden daher nicht mehr benötigt und zum überschreiben freigegeben. undo_retention bezieht sich nur auf committed undo data. -j

nein, undo-datenblöcke werden wie normale datenblöcke behandelt. das 'concepts'-buch in der oracle doku beschreibt es recht gut. -j

mein sqldeveloper (1.1.0.23) kann lobs anzeigen. -j

auch wenn > 4000 zeichen? -j

hat mich doch selbst interessiert. das war für mich ehrlich gesagt auch neu. ich frag mal bei den CBO experten nach. die frage ist, wird intern trotzdem komplett neu geparst oder ist das wie vermutet eher ein light-parse? ich frag mal bei Tom Kyte nach ich auch. -j

ok, ich hab nochmal meine 9i befragt und muss mich korregieren. irgendwie liegt meine OCP-prüfung zu weit zurück insofern danke für die frage, recht interessant. ok, zu dem test, siehe test.sql.txt. die stats und die ausführungspläne werden getrennt abgelegt, allerdings wird der ausführungsplan zusammen mit dem statement abgelegt. wird ein objekt analysiert, werden alle execution plans, die dieses objekt referenzieren, für ungültig erklärt. damit wird bei der nächsten ausführung des gespeicherten statements ein neuer execution plan erstellt. der testoutput sieht dann so aus: first LOADS INVALIDATIONS PARSE_CALLS OBJECT_STATUS PLAN_HASH_VALUE ---------- ------------- ----------- ------------------- --------------- 1 0 1 VALID 3844206385 changes LOADS INVALIDATIONS PARSE_CALLS OBJECT_STATUS PLAN_HASH_VALUE ---------- ------------- ----------- ------------------- --------------- 1 1 0 0 second LOADS INVALIDATIONS PARSE_CALLS OBJECT_STATUS PLAN_HASH_VALUE ---------- ------------- ----------- ------------------- --------------- 2 1 1 VALID 3918351354 stats-aktualisieren (changes) setzt parse-calls auf 0, invalidations auf 1 und löscht den ausführungsplan. beim nächsten zugriff (second) wird das statement reloaded/reparst und ein komplett neuer, anderer ausführungsplan erstellt. das ist IMHO aber kein kompletter hard-parse, würde keinen sinn machen, da das statement an sich unverändert ist und damit alle semantik/syntax-checks überflüssig sind. das statement an sich scheint im library cache zu verbleiben, nur der execution plan wird komplett neu erstellt. unter 10.2.0.3 sieht das ganze anders aus: first LOADS INVALIDATIONS PARSE_CALLS OBJECT_STATUS PLAN_HASH_VALUE ---------- ------------- ----------- ------------------- --------------- 1 0 1 VALID 3844206385 changes LOADS INVALIDATIONS PARSE_CALLS OBJECT_STATUS PLAN_HASH_VALUE ---------- ------------- ----------- ------------------- --------------- 1 0 1 VALID 3844206385 second LOADS INVALIDATIONS PARSE_CALLS OBJECT_STATUS PLAN_HASH_VALUE ---------- ------------- ----------- ------------------- --------------- 1 0 2 VALID 3844206385 auch wenn es nicht so aussieht, der plan von first (index range scan) ist ein anderer als der von second (table access full). keine invalidations, keine loads, lediglich ein neuer parse. -j test.sql.txt

wenn du mit geparsed == hard-parsed meinst, ja. der executionplan wird in der soft-parse phase entwickelt. lässt sich leicht testen. erstelle einfach eine tabelle mit einem index auf einem feld hoher selektivität. selects mit einer equal-klausel auf das feld werden den index verwenden. sobald das feld auf einen festen wert gesetzt wurde und die statistiken aktualisiert wurden, wird der CBO einen FTS verwenden. wichtig ist, dass das statement in beiden fällen absolut das gleiche ist, also nicht nochmal komplett geparst wird. -j

fast richtig. die ältesten und am wenigsten genutzten objekte werden gelöscht. nein, das statement wird nicht neu hard-geparst. soft-parse passiert bei jedem zugriff und dabei verwendet der CBO die neuen statistiken. siehe 2. statistiken und geparste statements werden getrennt abgelegt. -j

ja, genau so ist es. das aufräumen erledigt der smon. -j

achso, du meinst locking auf filesystemebene. da hst du generell recht, aber nicht das file wird gelockt, sondern nur der betroffene i-node. ein inode umfasst mindestens 1 filesystemblock, generell aber mehr. dadurch kann es zu überlappungen und damit zu wartezuständen kommen. je kleiner ein inode, desto besser oder gleich rawdevices nehmen. -j

das ist korrekt. DBWR hat mit den tempfiles nichts zu tun. jede session hat ihr eigenes temp-segment, da kommt es zu keinen inkonsistenzen oder blockierungen. -j

entscheidend ist, ob die führende spalte des index in der where-klausel enthalten ist. wenn ja, wird normaler index scan access verwendet, wenn nicht, index skip scan access verwendet. ob der index mehr spalten umfasst als in der where-klausel angegeben ist dabei irrelevant, Oracle kann die nicht benötigten indexeinträge ausfiltern. Oracle verwendet indizes, wenn mindestens eine spalte der where-klausel im index enthalten ist. das beschreibt aber nur die möglichkeiten seitens Oracle, ob ein index verwendet wird hängt vom CBO ab. in deinem fall, index umfasst mehr spalten als in where-klausel angegeben, kann es sehr gut sein, dass der indexzugriff zu teuer wird. -j

langsam, langsam, gibt noch ein leben neben der arbeit. prinzipiell ja. selbst wenn das prädikat der where-klausel nicht in den führenden spalten eines index vorkommt, kann oracle den index verwenden. das ganze nennt sich SKIP SCAN INDEX ACCESS und gibt es seit 9i. hat ein paar einschränkungen bezüglich des indextyps (keine bitmap, domain, reverse oder function-bases indizes). -j

lade die excel-datei im csv-format über 'EXTERNAL TABLE'. danach beide tabellen joinen und ergebnis mittels einer CURSOR LOOP und UTL_FILE in eine datei rausschreiben oder einfach per sqlplus in eine datei spoolen. wenn keine externe tabelle verwendet werden soll, kann man mi UTL_FILE auch die eingabedatei lesen. das kann man alles mit grundkenntnissen und der oracle doku zu UTL_FILE schaffen. -j

gehts irgendwie genauer? was geht nicht? -j

ja , das geht. es gibt ein paar vorraussetzungen wie gleiche version und gleiche hardwareplattform. am besten das dictionary als flat_file auf db a generieren und im logminer auf db b verwenden. -j

nun, ja, wenn du das unbedingt willst: init-parameter log_checkpoint_timeout / log_checkpoint_interval eine history an sich kenne ich nicht. macht auch keinen sinn, da locks sehr häufig gesetzt werden. entweder mit 'alter table x disable table lock' locking verbieten und warten bis die applikation einen fehler meldet oder mit logminer die redologs durchforsten. -j

select avg(preis) from (select sum(preis) preis from bestellungen where bestellid in (select bestellid from bestellungen where artikel='bier') group by bestellid); die zweite sieht genauso aus, nur statt 'not in' statt 'in'. -j

doppelpluszustimmung. -j

was reitest du auf INT rum? ich nehm sequences mit number(38) und habe damit mehr als 10^125 IDs, aber darum geht es hier überhaupt nicht. und was unter MS SQL schneller ist, ist ebenfalls nicht gefragt. unterhalte dich mal mit DB-Architekten, da ist die frage "surrogate keys oder natürliche keys" eine beliebte streitfrage. und das ist IMHO das, was der profi des OP meinte. -j