Jasper

die prüfungen sind nicht schwer. bringen tut es schon was, da man sich in der vorbereitungsphase auch mit themen beschäftigt, die man in der täglichen arbeit nicht bruacht. ich rate, einfach bei oracle university anzurufen und mit denen das ganze durchzugehen. die können dir auch sagen, ob die bereits absolvierten kurse anerkannt werden. -j

warte, bis du bescheid bekommst. personaler verhalten sich sehr oft absolut neutral, so dass man schnell den falschen eindruck bekommen kann. falls du abgelehnt wirst, frage nach den gründen. ist für das nächste mal sehr hilfreich. -j

ok, etwas detallierter. nochmal zurück zu deinem ersten statement: select dsks.dsqu_dsqu_id, dsks.dsks_status, to_char(dsks.dsks_zeitpunkt,'dd.mm.yyyy hh24:mi:ss')"Datum Zeit Sekunde", to_char(dsks.dsks_zeitpunkt,'sssss')"Dauer" from dsks, dsqu where dsks.dsqu_dsqu_id = dsqu.dsqu_id and dsks.dsks_status IN ('KP','ZV') and dsqu.kopa_kopa_id_nachricht_vers = 430 and dsks.dsks_zeitpunkt between to_date('01.01.2007 08:00:00','dd.mm.yyyy hh24:mi:ss')and to_date('05.07.2007 10:00:00','dd.mm.yyyy hh24:mi:ss') order by dsqu.dsqu_id desc, dsks_status desc; dsqu ist erstmal uninteressant, da es nur als filter (kopa_kopa_id_nachricht_vers = 430) und als order-argument fungiert. ebenso wird Dauer weggelassen, da es nicht das ist, was du erreichen wilst. in der where-klausel ist nur disks.dsks_status IN ('KP','ZV') relevant: select dsks.dsqu_dsqu_id, dsks.dsks_status, to_char(dsks.dsks_zeitpunkt,'dd.mm.yyyy hh24:mi:ss')"Datum", from dsks where dsks.dsks_status IN ('KP','ZV'); das ganze gibt etwas in der art aus: DSQU_DSQU_ID DS Datum ------------ -- ------------------- ----- 236680682 ZV 02.01.2007 16:37:11 236680682 KP 02.01.2007 16:37:12 um jetzt die zeitpunkte der zeilen mit status KP und ZV in eine zeile zu bekommen, werden erst 2 getrennte datensets für alle zeilen mit KP und ZV erstellt: select dsks_kp.dsqu_dsqu_id, dsks_kp.dsks_status, to_char(dsks_kp.dsks_zeitpunkt,'dd.mm.yyyy hh24:mi:ss')"Datum_KP" from dsks disks_kp where dsks_kp.dsks_status IN ('KP'); select dsks_zv.dsqu_dsqu_id, dsks_zv.dsks_status, to_char(dsks_zv.dsks_zeitpunkt,'dd.mm.yyyy hh24:mi:ss')"Datum_ZV" from dsks disks_zv where dsks_zv.dsks_status IN ('ZV'); und anschliessend über dsqu_dsqu_id miteinander verbunden, : select dsks_kp.dsqu_dsqu_id, dsks_kp.dsks_status Status_KP, dsks_zv.dsks_status Status_ZV, to_char(dsks_kp.dsks_zeitpunkt,'dd.mm.yyyy hh24:mi:ss') Datum_KP, to_char(dsks_zv.dsks_zeitpunkt,'dd.mm.yyyy hh24:mi:ss') Datum_ZV from dsks disks_kp join dsks disks_zv on dsks_kp.dsqu_dsqu_id=dsks_zv.dsqu_dsqu_id, where dsks_kp.dsks_status IN ('KP') and dsks_zv.dsks_status IN ('ZV'); das resultset sieht jetzt so aus: DSQU_DSQU_ID Status_KP Status_ZV Datum_KP Datum_ZV ------------ -- ------------------- ----- 236680682 KP ZV 02.01.2007 16:37:12 02.01.2007 16:37:11 jetzt kann die dauer zwischen ZV und KP ermittelt werden: select dsks_kp.dsqu_dsqu_id, dsks_kp.dsks_status Status_KP, dsks_zv.dsks_status Status_ZV, dsks_kp.dsks_status Status_KP-dsks_zv.dsks_status Status_ZV Dauer, to_char(dsks_kp.dsks_zeitpunkt,'dd.mm.yyyy hh24:mi:ss') Datum_KP, to_char(dsks_zv.dsks_zeitpunkt,'dd.mm.yyyy hh24:mi:ss') Datum_ZV from dsks disks_kp join dsks disks_zv on dsks_kp.dsqu_dsqu_id=dsks_zv.dsqu_dsqu_id, where dsks_kp.dsks_status IN ('KP') and dsks_zv.dsks_status IN ('ZV'); in Oracle wird die differenz zwischen zwei dates in tagen (oder bruckteilen davon) angegeben, also einfach mit 86400*1000 multiplizieren, um die differenz in millisekunden zu erhalten: select dsks_kp.dsqu_dsqu_id, dsks_kp.dsks_status Status_KP, dsks_zv.dsks_status Status_ZV, (dsks_kp.dsks_status-dsks_zv.dsks_status)*86400*1000 Dauer_in_ms, to_char(dsks_kp.dsks_zeitpunkt,'dd.mm.yyyy hh24:mi:ss') Datum_KP, to_char(dsks_zv.dsks_zeitpunkt,'dd.mm.yyyy hh24:mi:ss') Datum_ZV from dsks disks_kp join dsks disks_zv on dsks_kp.dsqu_dsqu_id=dsks_zv.dsqu_dsqu_id, where dsks_kp.dsks_status IN ('KP') and dsks_zv.dsks_status IN ('ZV'); jetzt noch die anfangs weggelassenen filter- und sortierbedingungen wieder hinzufügen und fertig ist das statement. -j

gibt dir aber umständen falsche ergebnisse. z.b.: tabelle TAB (id, status, zahl) mit folgenden werten: 1, 'A', 1 1, 'E', 2 2, 'A', 10 2, 'E', 20 A steht für anfang, E für ende. um die differenz zwischen zwischen A und E für jede id zu ermitteln: select a.id, b.num-a.num diff from test a join test b on a.id = b.id where a.col='A' and b.col='E'; damit werden die zeilen mit A mit den zeilen mit E über die id verknüpft und somit hat man innerhalb einer zeile zugriff auf die entsprechenden werte für num und kann damit die differenz bilden. das ergebnis sieht dann so aus: 1, 1 2, 10 -j

um die differenz zu erhaltren, kannst du entweder die tabelle mit sich selbst joinen oder analytische funktionen verwenden. analytische funktionen sind auf den ersten blick nicht einfach, die oracle doku hat dazu ist aber recht brauchbar. zur umrechnung: falls du nur sekundengenauigkeit hast, sind millisekunden nicht sehr sinnvoll. date1-date2*86400 ergibt sekunden. was mich etwas verwundert hat: to_char(datum, 'sssss') hat den alias 'dauer'. 'sssss' gibt doch nur die sekunden ab mitternacht an, willst du das? -j

in solchen fällen ziehe ich meine bewerbung zurück. ein solches verhalten lässt auf keine gute unternehmenskultur schliessen. ich erwarte eine eingangsbestätigung mit einer ungefähren angabe, wann ich wieder von dem unternehmen höre. ich bin kein bittsteller, sondern ein geschäftspartner und möchte als solcher behandelt werden. angebote zu telefonischen auskünften sollte man _immer_ wahrnehmen und dabei dem personaler löcher in den bauch fragen. am besten auch technische, oftmals reicht der personaler einen dann an den fachvorgesetzten weiter. und glaubt mir, kontakte sind bei bewerbungen immens wichtig. -j

warum nicht? verschlüssele einfach den payload mit AES. ist genauso, als ob ein file verschlüsselt und dann per ftp verschickt wird. Oracle hat in seinen datenbanken ein aehnliches feature. der schlüsselaustausch ist ein anderes thema. -j

weil 1 statement performanter ist als 2 getrennte, deren resultsets dann noch zusammengeführt werden müssen, wenn beide statements die gleichen daten lesen (wie in diesem fall). -j

man kann mit utf8 chinesische zeichen darstellen. ich würde aber zu der aktuellen unicode-implmentierung al32utf8 raten. in beiden fällen werden die erweiterten zeichen in 2x3bytes abespeichert. -j

spalte scannart in beiden tabellen indiziert? verteilung der werte innerhalb der spalten, fragen über fragen. wie sieht der ausführungsplan aus? poste mal den output, dass macht vieles einfacher. -j

wenn die speicheradressierung mit 32bit ausreicht, nimm 32bit. Oracle verwendet als primäre entwicklungsplattform für 32bit linux, für 64bit dagegen solaris. bugs werden auf den primären plattformen am schnellsten gefunden und man erhält am schnellsten patches dafür. alle anderen plattformen hinken z.t. erheblich hinterher. -j

wobei ich in diesem speziellen fall (prod- und test-instanz auf einer maschine) auch 2 listener verwenden würde. damit kann man diverse listener-einstellungen testen ohne das prod-system zu beeinträchtigen. ich bevorzuge in dem fall ip-aliases, d.h. der port bleibt gleich, der listener lauscht auf einer anderen ip-adresse. -j

wann und wie oft committed wird sollte man nicht von technischen fragen abhängig machen, committed wird immer so oft wie nötig. wenn 'datei erhalten' für sich eine abgeschlossene transaktion darstellt, gehört ans ende ein commit. aus vermeintlichen gründen an commits sparen zu wollen und damit die transaktion grösser zu fassen als sie es eigentlich ist, ist keine gute idee. sollte 'datei erhalten', 'date erfolgreich archiviert' insgesamt eine transaktion darstellen und du möchtest aber im fehlerfall die einzelnen schritte zurückrollen können, setze nach jedem schritt einen savepoint und ganz am ende ein commit. so kann jeder einzelne schritt zurückgerollt werden, allerdings hilft das nicht bei einem db-ausfall, dann wird trotzdem die gesamte transaktion zurückgerollt. -j

jede JAVA-IDE ist dafür geeignet. JDeveloper, Eclipse, JBuilder, etc., such dir eine aus. -j

ja, das ist korrekt und die übliche methode für controlfile recover. -j

und wie komme ich an das controlfile wieder heran, wenn das controlfile mit den metadaten des backupsets verloren ist? typisches henne-ei-problem. das controlfile mit den metadaten des backups sollte man getrennt von dem backupset speichern um im notfall wieder an die metadaten heranzukommen oder einen recovery catalog verwenden, was im bezug auf die metadaten das gleiche ist. -j

nur wenn sqlplus zum recovern verwendet wird. ab 9ir2 ist RMAN die erste wahl. es unterscheidet sich sehr wohl. zum einen hat das backup controlfile ein flag, was es als backup kennzeichnet, zum anderen sind die SCN marker für alle datenfiles auf 0xffffffff (unlimited) gesetzt. beim recovery wird dann das flag gelöscht und die marker auf die echten werten gesetzt. das gleiche procedere wie oben, nur gehen auch noch alle backupinformationen verloren. geht nicht anders, da die information, an welcher stelle im redologstream oracle stand, verloren ist. resetlogs definiert somit einen neuen anfangspunkt. generell RMAN für backup/recovery verwenden. sqlplus ist veraltet und wird nicht weiterentwickelt. -j

nicht 3? warum nicht einfach dem benutzer per permissions kein update/delete erlauben? -j

ohne indexing wird der join sehr teuer, da beide tabellen komplett gelesen werden müssen. wenn alleine das indizieren so lange dauert, dauert der join mindestens! ebenso lange. ich kann mir aber nicht vorstellen, dass mysql beim indizieren derartig langsam ist. oracle indiziert 400k zeilen in 5s, mysql dürfte ähnlich schnell sein. ich würde in der mysql-config und im plattensubsystem die ursache suchen. -j

ok, wollte nur sichergehen, dass auch daran gedacht wurde -j

300k und 40k würde ich nicht gerade riesig nennen. welches dbms ist denn im einsatz? sind die am join beteiligten spalten indiziert? -j

syntaktisch ja. ob logisch korrekt, hängt von der natur von den IPs ab. die müssen natürlich irgendwie matchen. der left join ist auch korrekt, so bekommst du als zugabe allen traffic, der keiner kst-ip zugeordnet werden kann. -j

den ANSI SQL standard gibt es in mehreren levels, den niedrigsten, entry level, unterstützen alle. AFAIK unterstützt Oracle ANSI SQL-99 (SQL92_SECURITY=TRUE gesetzt) voll, ebenso wie DB2. Postgresql unterstützt SQL99-entry, Mysql SQL92-entry. kann sich aber bei den neuesten version bereits geändert haben. zu den unterschieden: http://www.little-idiot.de/linuxsolutionguide/datenbanken.htm -j

und was ist mit privilegien, die über eine rolle erteilt wurden? -j

da gibt es keine faustregel. der CBO berechnet die kosten der zugriffspfade und wählt den mit den wenigsten kosten aus. clustering factor ist nur ein faktor in der gleichung, systemstatistiken soielen eine rolle, ebenso wie index-selektivität, range, etc. pp. -j