Oracle-Ansichtssperre und Sitzungsausführungs-SQL (Zusammenfassungsfreigabe)

Dieser Artikel bringt Ihnen relevantes Wissen über Oracle, das hauptsächlich Probleme im Zusammenhang mit der Überprüfung von Sperren und SQL bei der Sitzungsausführung behandelt. Ich hoffe, es wird für alle hilfreich sein.

Empfohlenes Tutorial: „Oracle Video Tutorial“

Datenbankumgebung für die Testdaten dieses Artikels: Oracle 11g

Warum heißt es, dass es sich bei der Sitzungsausführung um SQL handelt? Die Aufzeichnung einer bestimmten Sitzung kann nicht abgerufen werden. Ich habe auch viele Blog-Beiträge gelesen, die besagten, dass die SQL-Ausführungsaufzeichnung einer bestimmten Sitzung abgefragt werden kann, indem die sql_id mit der Ansicht v$active_session_history und v$ verknüpft wird sqlarea. Nach dem Üben wurde festgestellt, dass dies nicht möglich ist (durch die Tabelle dba_hist_active_sess_history versucht. Es funktioniert auch nicht), die sql_id einiger SQL wird überhaupt nicht in v$active_session_history aufgezeichnet. Ich habe versucht, den Parameter zu ändern : control_management_pack_access und festgestellt, dass ich keine Berechtigung hatte. Und ich habe es überprüft und festgestellt, dass der Parameterwert normal und die Parameterdatenbank geöffnet ist, siehe Blog-Beitrag: Oracle V$ACTIVE_SESSION_HISTORY query has no data – wazz_s – Blog Park

Der Ausführungsdatensatz von SQL kann über die v$sqlarea-Ansicht abgefragt werden, aber die Sitzungs-ID, die die SQL ausführt, kann nicht gefunden werden. Es wäre großartig, wenn es eine solche Sitzungs-ID gäbe. Ich kann herausfinden, wer die SQL ausgeführt hat .

Wenn ich die SQL abfragen möchte, die die Sperrung der Tabelle verursacht hat, lehren die meisten Blog-Beiträge im Internet dies, indem ich die Ansicht v $ session abfrage, ihn als Wert A aufzeichne und dann Verwenden Sie Wert A als Der Abfragebedingungswert des Adressfelds in der Ansicht v$sqlarea, und dann kann der entsprechende SQL-Datensatz abgefragt werden. Als Übungstest können Sie die SQL finden, die die Sperrtabelle findet, aber in den meisten Fällen können Sie sie nicht in einer normalen Produktionsumgebung erhalten. Warum? Bitte lesen Sie die Einführung unten.

Dieser Artikel verwendet einen explorativen Ansatz zum Studieren. Um die Genauigkeit der Daten sicherzustellen, habe ich drei Datenbanksitzungen geöffnet, die als Sitzung1, Sitzung2 und Sitzung3 aufgezeichnet wurden:

1 in Sitzung Sitzung1 Erstellen Sie eine neue Testtabelle und testen Sie Daten.

--新建测试表
create table zxy_table(zxy_id int,zxy_name varchar2(20));
--插入数据
insert into zxy_table(zxy_id,zxy_name) values(1,'zxy1');
insert into zxy_table(zxy_id,zxy_name) values(2,'zxy2');
insert into zxy_table(zxy_id,zxy_name) values(3,'zxy3');
insert into zxy_table(zxy_id,zxy_name) values(4,'zxy4');
commit;

2 Sehen Sie sich die Sitzungs-ID von Sitzung1 an Tabelle zxy_table über „select for update“ wie folgt:

 select userenv('sid') from dual;

4 Fragen Sie in Sitzung2 ab, ob die Sitzungs-ID 2189 ist:

Aktualisieren Sie dann in Sitzung2 die Zeile mit dem zxy_table-Wert zxy_name='zxy1' in Sitzung2 wie folgt :

 select * from zxy_table where zxy_name='zxy1' for update;

Dann schauen Sie, dass SQL blockiert wurde, wie unten gezeigt:

5 Dann kamen wir zu Sitzung 3, um die Sperrtabellensituation zu überprüfen

Überprüfen Sie zuerst die Tabelle v$locked_object

update zxy_table set zxy_name='zxy1_modify' where zxy_name='zxy1';

Sie Sie können sehen, was die Sperrtabelle verursacht hat. Die Sitzungs-ID ist 2546, also die vorherige Sitzung1, und die Objekt-ID ist 110154. Natürlich werden Sie in der Generierungsumgebung definitiv mehr als einen Datensatz sehen. Sie müssen ihn mehrmals ausführen. Nachdem Sie es n-mal ausgeführt haben, können Sie die Datensätze immer noch sehen und beweisen, dass es sich bei diesem Datensatz um den Datensatz der Sperrtabelle handelt. Fragen Sie die detaillierten Sperrtabelleninformationen über die Objekt-ID: 110154

dba4_objects-Tabelle ab. Fragen Sie die Ansicht ab v$session

select * from v$locked_object;

durch sessionid: 2546 erhalten prev_sq l_addr Der Wert ist: 000000012E045E28, und fragen Sie dann die Ansicht v$sqlarea

select object_name as 被锁的表名称,obj.* from dba_objects obj where object_id='110154';

über den erhaltenen Wert ab. Aus dem Bild oben können Sie sehen die Anweisung, die die Tabellensperre verursacht hat, aber viele Blog-Beiträge sind in diesem Schritt abgeschlossen, sodass die Abfrage wirklich lautet: Ist sie zuverlässig? Die Antwort ist unzuverlässig. Sie können nach Belieben zu Sitzung 1 zurückkehren und eine SQL wie folgt ausführen:

select 
       s.prev_sql_addr,
       module as 客户端工具名称,
       s.user# as 数据库账号名,
       s.osuser as 连接数据库客户端对应的window账号名称,
       s.machine as 连接数据库客户端对应的计算机名称,
       s.* 
from v$session s where sid='2546';

Dann können Sie sie in Sitzung3 ausführen

select * from v$sqlarea where address='000000012E045E28';

 再看看prev_sql_addr是不是变了，从000000012E045E28变为了00000001FB03CEC0，再通过00000001FB03CEC0查询视图v$sqlarea

select * from v$sqlarea where address='00000001FB03CEC0';

得到的sql_text是select * from zxy_table，你敢说这条sql导致了锁表吗？所有只能说是session1当前执行的sql，而且你很难保证session1执行完锁表的sql： select * from zxy_table where zxy_name='zxy1' for update且在提交前不再执行别的sql，这就是前文提出的问题的答案。

推荐教程：《Oracle视频教程》

Das obige ist der detaillierte Inhalt vonOracle-Ansichtssperre und Sitzungsausführungs-SQL (Zusammenfassungsfreigabe). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!