Database Reference
In-Depth Information
Dies brachte mich auf die Idee, zu prüfen, wie viele Objekte diese Datenbank hatte.
SQL> select count(*) from obj$;
COUNT(*)
----------
314607
SQL> select count(*) from seg$;
COUNT(*)
----------
297579
Es gab also ca. 300 Tausend Objekte, die meisten davon waren Segmente. Danach stellte
ich fest, dass diese Segmente zu den ca. 200 Datenbankschemata gehörten. Diese Daten-
bankschemata waren identisch aufgebaut, und ihre Objekte hatten dieselben Namen. Aus
diesem Grund vermutete ich, dass die Cursor-Listen bei diesem System ziemlich lang sein
können. Das prüfte ich sofort.
SQL> select * from (select sql_id,count(*) from v$sql where is_obsolete = 'N'
group by sql_id
order by 2 desc) where rownum <= 10;
SQL_ID COUNT(*)
------------- ----------
88ryrt27vzky6 984
ccsscq5qbq7nx 962
dzanvsamz904d 838
8kzw1xbfh6bdn 832
0mynpn1uyndgk 819
9nsxd436hfph4 798
5pz0zr52kzmn9 796
aq7wq5ky99zrj 762
3v9ty66zax1w1 759
3pfu180cp615t 684
10 rows selected.
Der häufigste Grund von der nicht gemeinsamer Nutzung dieser Cursor war die fehlge-
schlagene Authentisierung (AUTH_CHECK_MISMATCH='Y' in der View V$SQL_SHA-
RED_CURSOR). Obwohl die jeweiligen SQL-Anweisungen als SQL-Texte identisch wa-
ren, mussten sie aber für die verschiedenen Schemata geparst werden. Aus diesem Grund
konnten die jeweiligen Cursor nicht gemeinsam genutzt werden. Bei der Suche nach einem
für die gemeinsame Nutzung geeigneten Cursor in den langen Cursor-Listen, welche je-
weils beim Parsing stattfand, wurde auf das Data Dictionary häufig zugegriffen. Es kam
dabei zu sehr großen Wartezeiten auf „latch: row cache objects“ in den Bereichen dc_ob-
jects und dc_object_grants vom Row Cache. Die Ursache des Performanz-Problems war
also klar, unklar blieb aber die Problemlösung.
Für solche Systeme implementiert man normalerweise ein Mandantenkonzept, welches
erlaubt, jeweils auf die Mandantendaten mit einem Cursor zuzugreifen (statt einen Cursor
pro Mandant zu haben). Deswegen sind die Längen der Cursor-Listen N-mal kürzer als
