Database Reference
In-Depth Information
SQL> alter session set "_cursor_obsolete_threshold"=200;
Session wurde geändert.
SQL> declare
2 stmt varchar2(2000):='alter session set "_smm_px_max_size"=';
3 m number;
4 begin
5
6
for i in 1..1025 loop
7
execute immediate stmt || to_char(100000 + i,'999999999');
8
select 1 into m from dual;
9
end loop;
10 end;
11 /
PL/SQL-Prozedur erfolgreich abgeschlossen.
SQL> select address, sql_id, is_obsolete, count(*), min(child_number),max(child_number) from
v$sql where force_matching_signature=10559245208183986822 group by address, sql_id,
is_obsolete order by is_obsolete desc, address;
ADDRESS SQL_ID IS_OBSOLETE COUNT(*) MIN(CHILD_NUMBER) MAX(CHILD_NUMBER)
---------------- ------------- ----------- ---------- ----------------- -----------------
000007FF5F2C0618 bunvx480ynf57 Y 200 0 199
000007FF5F6980F8 bunvx480ynf57 Y 200 0 199
000007FF5F6BC0A0 bunvx480ynf57 Y 200 0 199
000007FF5F82C9B0 bunvx480ynf57 Y 200 0 199
000007FF5F8A70A0 bunvx480ynf57 Y 200 0 199
000007FF5F1D15A8 bunvx480ynf57 N 25 0 24
Setzen wir den Parameter
_
cursor
_
obsolete
_
threshold
auf 200 und wiederholen den Test-
Case von oben für Oracle 11.2.0.3.
Statt einer Cursor-Liste für den Select entstehen hier 6, aber nur die 25 Cursor aus der
letzten Liste können für die künftigen Cursor gemeinsam genutzt werden. Die restlichen
Cursor-Listen werden nicht mehr bei der Suche nach einem Cursor für gemeinsame Nut-
zung aufgesucht und können aus diesem Grund die Performanz nicht beeinträchtigen.
8.3
Performanz-Probleme bei langen Cursor- Listen
Wenn Oracle nach einem passenden Cursor in einer langen Cursor-Liste sucht, kann der
Aufwand gravierend sein. Für die Suche selbst wird hauptsächlich CPU verbraucht. Die
Konkurrenz beim Parsing kann dabei auch entsprechende Wartezustände verursachen. In
den nächsten Abschnitten sind zwei Performanz-Probleme wegen der langen Cursor-Lis-
ten beschrieben.
8.3.1
Performanz-Problem mit vielen Datenbankschemata
Dieses Problem trat bei einer Datenbank von Oracle 10.2.0.4 auf und äußerte sich in sehr
großen Wartezeiten auf „latch: row cache objects“ (s. die Abb.
8.1
).
Mit dem Skript latch_rowcache_obj_where_waits9.sql ermittelte ich, dass die zwei Be-
reiche vom Row Cache davon betroffen waren: dc_objects und dc_objects_grants.
