Jasper

es macht keinen sinn, numerische IDs durch Text-IDs zu ersetzen. allerdings meint dein profi vermutlich etwas anderes: den einsatz von surrogate keys. sollte man einen künstlichen key als primärschlüssel verwenden, wenn ein datensatz durch ein natürliches feld bereits eineindeutig identifiziert wird? -j

USER ist eine funktion und damit ein reservierter name. eigentlich eine schlechte wahl für eine spalte aber in "" gesetzt, funktioniert es auch damit. -j

wenn offline und online genauso lang dauert, kann es sich nicht um grosse tabellen handeln. offline kann den vorhandenen index nutzen, online macht _immer_ ein full table scan: > alter index dummy1 rebuild; ---------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | ---------------------------------------------------------------------- | 0 | ALTER INDEX STATEMENT | | | | | | 1 | INDEX BUILD NON UNIQUE| DUMMY1 | | | | | 2 | SORT CREATE INDEX | | | | | | 3 | INDEX FAST FULL SCAN| DUMMY1 | | | | ---------------------------------------------------------------------- > alter index dummy1 rebuild online; ---------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | ---------------------------------------------------------------------- | 0 | ALTER INDEX STATEMENT | | | | | | 1 | INDEX BUILD NON UNIQUE| DUMMY1 | | | | | 2 | SORT CREATE INDEX | | | | | | 3 | TABLE ACCESS FULL | DUMMY | | | | ---------------------------------------------------------------------- und zumindest bei mir ist ein index fast full scan _immer_ schneller als ein table scan, wenn die tabelle grösser als ein paar blöcke ist. -j

man kann nicht mit NOWAIT locken. WAIT/NOWAIT bezieht sich auf den lockrequest. DDL arbeitet immer mit NOWAIT. -j

ein offline-rebuild setzt ein exclusives DML-lock (kein insert, update, delete, merge möglich) auf die tabelle. die tabelle während des indexaufbaus zu ändern ist generell keine gute idee. der index wird aber nicht im TEMP-tablespace erstellt, dort landet nur das temporäre sort-segment. wenn der rebuild den vorhandenen index verwenden kann (ist die regel), dann steht der index auch während des rebuilds für queries zur verfügung. ein online-rebuild dagegen baut parallel einen zweiten index in form einer IOT auf. alle änderungen auf den vorhandenen während des rebuild werden in einem journal vermerkt. deshalb kann auch nicht der vorhandene index für den rebuild genutzt werden. die tabelle wird nur kurz zu beginn und am ende für DML gesperrt. offline geht schnell, vor allem, wenn der vorhandene index genutzt werden kann und benötigt weniger resourcen. nachteil ist das DML-lock für die dauer des rebuilds. online hat zwar kein DML-lock, benötigt aber bedeutend mehr resourcen und dauert länger als offline. wenn möglich immer offline-rebuild bevorzugen, auch wenn DML vielleicht für die dauer des rebuild 'hängen'. wenn es gar nicht anders geht, online verwenden. -j

...und die lautet wie? das GROUP BY ist falsch/überflüssig. das SELECT liefert sowieso nur einen einzelnen wert zurück, sonst wird das schwierig mit der zuweisung. andererseits würde ich mir nochmal ganz genau überlegen, ob ich wirkich für jedes DML-statement auf CITY _ALLE_ werte in country aktualisieren will. man kann das auch so lösen (ungetestet): CREATE or replace TRIGGER ins_country AFTER INSERT ON city for each row BEGIN UPDATE country SET population = population + :new.population where code = :new.country; END; CREATE or replace TRIGGER upd_country AFTER UPDATE of population ON city for each row BEGIN UPDATE country SET population = population + (:new.population - :old.population) where code = :old.country; END; CREATE or replace TRIGGER del_country before DELETE ON city for each row BEGIN UPDATE country SET population = population - :old.population where code = :old.country; END; und du solltest _zwingend_ die relation zwischen CITY und COUNTRY definieren. dein schöner plan funktioniert nämlich überhaupt nicht, wenn für eine einfügte stadt noch gar kein land existiert. und country.population und city.population darf nicht NULL sein und sollte per default auf 0 stehen (ansonsten muss auf NULL in den triggern getestet werden)! ausserdem darf keiner auf die idee kommen, eine stadt mal kurz in ein anderes land zu verfrachten. das lässt sich aber einfach mit einem zweiten update im UPDATE-trigger lösen. -j

psp steht für process spawner und dient zum starten und verwalten von anderen oracle prozessen. ist allerdings nicht in der aktuellen dokumentation nicht dokumentiert, also keine details verfügbar. -j

erstelle einfach eine neue kopie in DATA mit 'backup as copy' und switche zurück. -j

RPAD() und/oder LPAD() füllt strings auf. -j

das stimmt in der default-konfiguration nicht. der default für NLS_LENGTH_SEMANTICS ist BYTE und damit bezeichnet varchar2(20) einen string von 20 BYTES länge und das sind nur bei singlebyte-zeichensätzen auch 20 zeichen. -j

such nach 'zip codes netherlands' oder gleich hier http://en.wikipedia.org/wiki/Lists_of_postal_codes -j

nein. datenbank runterfahren, intakte kopie kopieren , datenbank hochfahren. gibt keine andere möglichkeit. -j

insert into b (id) select id from a where id not in (select id from ; -j

insert into <tabelle_b> (barcode,null_spalte) select barcode,null from tabelle_a; -j

das sieht nach datenkorruption aus. setz doch mal analyze table leistung validate structure cascade; ab. kann aber gut sein, dass analyze nichts findet. -j

für objekte ja, siehe z.b. dba_tab_privs.grantor. für systemrechte AFAIK nein. -j

die liste jedesmal neu zu berechnen find ich suboptimal. was spricht gegen die variante mit count(*)? mit einem index auf die punktespalte ist das performant und einfach zu implementieren. -j

select count(*) from tab where punkte >= (SELECT punkte from tab where username = 'USER'); keine ahnung ob mysql das so kann, anderenfalls in 2 statements zerlegen. falls gleiche punktzahl einem einzelnen rang zugeordnet werden sollen, muss man count(distinct punkte) statt count(*) verwenden. -j

es gibt 3 OEM-Consolen: 1. JAVA 2. Webapplikation DB-Console 3. Webapplikation Grid Control weiterentwickelt werden nur 2. und 3. ich nehme an, du verwendest 1. und der hinweis bedeutet, du sollst auf 2. oder 3. wechseln. -j

das einzige, was dem resourcenmanager wirklich fehlt sind I/O-limite. ansonsten ist er recht brauchbar. den resourcenverbrauch festzustellen dürfte nicht ganz einfach sein, da dieser von einer ganzen anzahl von faktoren abhängt, die im laufenden betrieb nur sehr schwer zu erfassen sind (cache hits, i/o-distribution, system-aktivitäten, etc. pp.). das gleiche gilt für die momentane auslastung des servers (intervallmessung). ich würde den resourcenmanager einsetzen in zusammenhang mit profiles. -j

trunc() schneidet nachkommastellen einfach ab, ohne auf- oder abrunden. -j

9.2.0.1 ist elende alt und hat diverse bugs mit ansi joins. du solltest mindestens auf 9.2.0.4 oder besser gleich auf 9.2.0.6/7 gehen. -j

bei einem hard parse, wenn bind variablen auf histogram-spalten verwendet werden, wird bind peeking verwendet, d.h. der wert der bind variablen wird wie ein literal angesehen. bei nachfolgenden soft-parses werden dagegen sowohl die histogramme als auch die bind variablen ignoriert und der gecachte plan verwendet. -j

der wert der bindvariablen legt beim hard parse den execution plan fest. selbst wenn aufgrund des histograms danach ein anderer exeution plan vorteilhafter wäre, wird kein neuer plan erstellt solange der im shared pool gültig ist. -j

ein index ist bereits sortiert, daher ist die reihenfolge, in der die einzelnen zeilen zurückgegeben werden, vorgegeben und zwar in exakt der gleichen reihenfolge in der der index aufgebaut ist, weil der zugriffspfad indexentry->rowid ist. bei einem tablescan wird die tabelle von ersten block bis zur HWM gelesen. bei heap-tables können die rows vollkommen ungeordnet in den blöcken liegen, die reihenfolge entspricht dann der reihenfolge der rows in den blöcken. -j