Jasper

wenn sampling zu den gleichen ausführungsplänen führt, werde ich nicht stunden- bis tagelang irgendwelche statistiken generieren nachdem ende des monats ein neuer datenblock geladen wurde. das wäre 'blödsinnig'. dann hab ich halt 800G bilderbuchdaten. vielleicht liest du mein posting nochmal, ich schrieb "keine histogramme _per default_". histogramme machen probleme mit bindvariablen, mit VARCHAR/CHAR, bei denen die ersten 32 bytes sich nicht signifikant unterscheiden und haben oftmals keinen einfluss auf den ausführungsplan. wolfgang breitling und dave ensor haben dazu recht gute papers verfasst, ebenso wie jonathan lewis. jede datenbank, die von leuten rund um den globus genutzt wird, hat probleme mit solchen fenstern, wobei man ab einer gewissen grösse die statistiken nicht mehr eben nebenbei erstellen kann. fluglinien und telcos kennen das problem nur zu gut. spekulationen kommentiere ich nicht. -j

GATHER_STATS_PROG verwendet auto-sample, was vor allem bei grossen datenbanken (>250G) ziemlicher unsinn ist. da ist estimate mit festem prozentwert (2-5) um längen besser. RBO kennt keine der neuen features ab oracle 7. bitmap-index, hash joins, etc. kann man damit vergessen. kommt drauf an. gerade bei temporary tables oder im DWH (bei tabellen mit gleichverteilten daten) ist dynamic sampling von vorteil. histogramme zu erstellen ist resourcenintensiv und lohnt sich nur für spalten mit ungleichverteilten daten oder bei abhängigkeiten zwischen spalten. ich würde keine histogramme per default erstellen. -j

dynamic sampling wird auf das feld unter verwendung des index angewendet. ich sehe schon, um einen 10053 komme ich nicht herum (ich habe alles unwesentliche weggelassen): tabelle dyn wurde erstellt mit 'CTAS * from dba_objects', der index mit 'craete index ix1 on dyn(owner)', alle statistiken für tabelle und index wurden gelöscht. das sql-statement zum testen ist "select * from dyn where owner='DUMMY'", welches ca. 40 zeilen zurückgeben sollte. kommentare von mir beginnen mit >>: *************************************** BASE STATISTICAL INFORMATION *********************** Table Stats:: Table: DYN Alias: DYN (NOT ANALYZED) #Rows: 12990 #Blks: 319 AvgRowLen: 100.00 >> für AvgRowLen wird der default 100 verwendet, #Blks (anzahl blöcke unter HWM) ist >> aus dem segmentheader bekannt, #Rows errechnet sich dann wie folgt: >> #Rows = #Blks * (blocksize-blockheadersize) / AvgRowLen >> blocksize ist 4096 bytes, blockheadersize=24 bytes -> 12990 rows Index Stats:: Index: IX1 Col#: 1 (NOT ANALYZED) LVLS: 1 #LB: 25 #DK: 100 LB/K: 1.00 DB/K: 1.00 CLUF: 800.00 >> auch hier defaults: jeder index ohne stats wird als level1 mit 25 LB angesehen *************************************** SINGLE TABLE ACCESS PATH *** 2006-06-05 12:48:24.394 ** Performing dynamic sampling initial checks. ** Column (#1): OWNER(VARCHAR2) NO STATISTICS (using defaults) AvgLen: 30.00 NDV: 406 Nulls: 0 Density: 0.0024634 ** Dynamic sampling initial checks returning TRUE (level = 2). ** Dynamic sampling updated index stats.: IX1, blocks=61 ** Dynamic sampling index access candidate : IX1 ** Dynamic sampling updated table stats.: blocks=319 *** 2006-06-05 12:48:24.418 ** Generated dynamic sampling query: query text : SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0) FROM (SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("DYN") FULL("DYN") NO_PARALLEL_INDEX("DYN") */ 1 AS C1, CASE WHEN "DYN"."OWNER"='DUMMY' THEN 1 ELSE 0 END AS C2 FROM "DYN" SAMPLE BLOCK (19.749216 , 1) SEED (1) "DYN") SAMPLESUB *** 2006-06-05 12:48:24.422 ** Executed dynamic sampling query: level : 2 sample pct. : 19.749216 actual sample size : 2527 filtered sample card. : 8 orig. card. : 12990 block cnt. table stat. : 319 block cnt. for sampling: 319 max. sample block cnt. : 64 sample block cnt. : 63 min. sel. est. : 0.01000000 ** Using recursive dynamic sampling card. est. : 12795.444444 >> level 2 sampling, d.h. 64 blocks ergibt eine estimated cardinality von 12795, die tabelle hat genau 11438, also ca. 10% daneben *** 2006-06-05 12:48:24.422 ** Generated dynamic sampling query: query text : SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS opt_param('parallel_execution_enabled', 'false') NO_PARALLEL(SAMPLESUB) NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0), NVL(SUM(C3),0) FROM (SELECT /*+ NO_PARALLEL("DYN") INDEX("DYN" IX1) NO_PARALLEL_INDEX("DYN") */ 1 AS C1, 1 AS C2, 1 AS C3 FROM "DYN" "DYN" WHERE "DYN"."OWNER"='DUMMY' AND ROWNUM <= 2500) SAMPLESUB >> wie man hier sieht, erfolgt das sampling auf der tabelle unter benutzung von IX1 (siehe hint) *** 2006-06-05 12:48:24.424 ** Executed dynamic sampling query: level : 2 sample pct. : 100.000000 actual sample size : 12795 filtered sample card. : 41 filtered sample card. (index IX1): 41 orig. card. : 12795 block cnt. table stat. : 319 block cnt. for sampling: 319 max. sample block cnt. : 4294967295 sample block cnt. : 319 min. sel. est. : 0.01000000 index IX1 selectivity est.: 0.00320427 ** Using dynamic sampling card. : 12795 ** Dynamic sampling updated table card. ** Using single table dynamic sel. est. : 0.00320427 >> diese selectivity von 0.00320427 errechnet sich aus sampled cardinality der tabelle >> von 12795 und des index von 41, d.h. der optimizer nimmt aufgrund des dynamic >> sampling an, dass die tabelle 12795 rows hat und das jeder disctinct value des index >> auf 41 rows der tabelle verweist Table: DYN Alias: DYN Card: Original: 12795 Rounded: 41 Computed: 41.00 Non Adjusted: 41.00 Access Path: TableScan Cost: 40.31 Resp: 40.31 Degree: 0 Cost_io: 40.00 Cost_cpu: 4422632 Resp_io: 40.00 Resp_cpu: 4422632 Access Path: index (AllEqRange) Index: IX1 resc_io: 4.00 resc_cpu: 29403 ix_sel: 0.0032043 ix_sel_with_filters: 0.0032043 Cost: 4.00 Resp: 4.00 Degree: 1 Best:: AccessPath: IndexRange Index: IX1 Cost: 4.00 Degree: 1 Resp: 4.00 Card: 41.00 Bytes: 0 der rest ist normale optimizer-rechnerei. auf das predicate owner=DUMMY treffen 41 aus 11438 zeilen zu, daher gewinnt hier der indexzugriff mit seiner besseren selectivity. das sollte deine fragen beantworten. -j

es werden einfach standardwerte für die verschiedenen CBO-parameter angenommen, z.b btree-level (1), selectivity für bound (0.0025), unbound (0.05) ranges, etc.pp. diese werte werden nicht gespeichert und sind nicht einsehbar (ausser mit einem 10053 trace). genauso wie mit statistiken, sind keine da -> sampling, sampling nicht möglich -> defaults wieso soll das klar sein? bei RBO ja, bei CBO nicht. sampling wird auch bei indizes angewendet. -j

richtig. der CBO erstellt stats on-the-fly mittels dynamic sampling. falls das nicht möglich ist (feature abgeschalten oder bei bestimmten tabletypen) werden defaults verwendet. die frage verstehe ich nicht. -j

z.b. mit subselect: select name from presis where m_year in (select m_year from presis group by m_year having count(*) > 1); allerdings unterstützen nicht alle RDBMS subselects. -j

dein statement ist richtig, aber in den spalten sind nichtnumerische werte. konvertiere die spalten zu number, das ist die sauberste lösung. -j

du suchst 'emca'. -j

datenbankserver brauchen vor allem eines: I/O-durchsatz mit geringer latenz. und ein gutes I/O-system kostet geld. das verwendete OS und RDBMS ist zweitrangig wenn die Hardware den Duchsatz nicht bringt. und ein dicker server hat ein vernünftiges I/O-system, ist also sehr wohl für datenbanken geeignet. und deine AS/400 als midrange kann vor allem eines: daten hin- und herschieben, ist also vorzüglich für datenbanken geeignet. zu den preisen: hängt immer ab, was man mit der hardware anstellen will. wenn wir hier von Oracle oder DB2 reden sind 1K oder 2K EUR für die hardware lächerlich, da kostet ja der support für eine einzelne CPU 3-6x soviel. ich würde mit postgres anfangen, und sehen, wie weit man damit kommt. postgres hat MVCC und die wichtigsten indextypen, ausserdem PITR und tabellenpartitionierung. alles features, die man bei datenmengen > 100G gern haben möchte. wenn postgres nicht reicht, wechselt man halt auf ein schwergewicht wie Oracle, DB2 oder Sybase. -j

ich würde USER_CONS_COLUMNS abfragen, da er ja als der Schemaowner angemeldet ist. -j

man muss es ja nicht gleich übertreiben. 'grant select_catalog_role' statt 'grant dba' tut es auch. -j

table-constraints müssen nicht unbeding sein, in diesem fall kann man auch den column constraint mit namen anlegen: CREATE TABLE test3( NR INTEGER PRIMARY KEY, XYZ INTEGER constraint fk1 REFERENCES test2(vct) ) aber ansonsten stimme ich dir vollkommen zu, constraints sollten _immer_ mit namen angelegt werden. -j

gibt es schon, aber nur bei PL/SQL. als SQL-Datentyp gibt es kein BOOLEAN. -j

sql als sprachkonstrukt ist per definition nicht intelligent, ebensowenig wie php, java oder fortran. unter oracle kann man das problem mit CASE lösen: per CASE wird anhand des proprtynamens eine virtuelle spalte generiert, anhand der sortiert werden kann. SELECT Properties.activity_id, Properties.property_name, case Properties.property_name when "What" then 0 when "Where" then 1 when "Who" then 2 else 99 end sort_col FROM Properties WHERE (((Properties.property_name)="What" Or (Properties.property_name)="Where" Or (Properties.property_name)="Who")) order by sort_col alles ungetestet, syntaxfehler nicht ausgeschlossen. -j

die fehlermeldung ist doch sehr eindeutig. du hast das komplette exceptionhandling vergessen. sowohl Class.forName() als auch DriverManager.getConnection() können exceptions werfen. im einfachsten fall einfach einen try/catch()-block um beide statements: try { Class.forName(dbdriver); return DriverManager.getConnection (dburl, dbuser,dbpassword); } catch (Exception e) { System.err.println(e); } alternativ kann auch die deklaration methode connect() ändern: private Connection connect() throws Exception dann muss allerdings das exception-handling weiter oben erfolgen. du solltest dich allerdings vorher mit den grundlagen vertraut machen, exception-handling gehört zu den grundlagen. -j

flashback query und flashback table verwenden den gleichen mechanismus und ausschliesslich undo. die flashback logs sind nur für flashback database. -j

proc start as begin proc1; proc2; proc3; end; / -j

mit Oracle kein Problem: SQL> select * from tabelle1; FELD1 FELD2 ---------- ---------- 1 1 SQL> select * from tabelle2; FELD1 FELD2 ---------- ---------- 1 2 SQL> update tabelle1 t1 set feld2 = (select t2.feld2 from tabelle2 t2 where t1.feld1 = t2.feld1); 1 row updated. SQL> select * from tabelle1; FELD1 FELD2 ---------- ---------- 1 2 wundert mich ehrlich, dass das mit DB2 nicht geht. -j

ich habe deine erklärung nicht ganz verstanden, aber anhand des statements oben denke ich mal, du suchst das hier: update tabelle1 t1 set feld2 = (select t2.feld2 from tabelle2 t2 where t1.feld1 = t2.feld1); -j

ob 20min für ein select eine ewigkeit sind, lässt sich nicht pauschal sagen. in DWH sind abfragen mit mehreren stunden laufzeit völlig normal und diese abfragen sind hochoptimiert. -j

ich meine vor dem update auf 9.2.0.6 (allerdings RAC) eine metalink-note gelesen zu haben, die ein upgrade mit umweg über 9.2.0.4 empfiehlt. wenn ich die note noch finde, reiche ich die ID nach. aber vielleicht bringe ich da auch was komplett durcheinander. wenn es direkt klappt, um so besser. -j

du willst nicht alle patches, sondern nur patchsets (sammlung von patches) + letztes CPU (kritsche patches). an die patchsets kommt man über advanced search ran, als patch type 'patchset' angeben. im fall von 9.2.0.1 gilt folgende reihenfolge: 9.2.0.1->9.2.0.4->9.2.0.6 (9.2.0.7 ist schrott, würde ich nicht verwenden). du musst also 2 mal patchen, ist aber nach lektüre der readme kein problem. danach nach belieben noch das letzte CPU (CPUOct2005) draufpacken. -j

das ist auch heute noch so. little endian auf big endian ohne konvertierung geht nicht. 10g-RMAN hat dafür 'convert', ansonsten geht nur export/import. -j

create or replace trigger tab_trig before insert on tab for each row declare dummy number; begin select 1 into dummy from tab where id = :new.id; raise_application_error(-20000, 'dup_id: '||:new.id); exception when NO_DATA_FOUND then null; when OTHERS then raise; end tab_trig; / liefert bei bereits vorhandener id den fehler ora-20001 mit fehlertext 'dup_id: <id>' zurück. -j

und was hast du im installer als verzeichnis für das inventory und oracle home angegeben? waren die env-variablen beim installieren überhaupt aktiv? -j