verrouillage de la vue Oracle et exécution de la session SQL (partage du résumé)

Cet article vous apporte des connaissances pertinentes sur Oracle, qui présente principalement les problèmes liés à la vérification des verrous et de SQL lors de l'exécution de session. Examinons-le ensemble, j'espère qu'il sera utile à tout le monde.

Tutoriel recommandé : "Tutoriel vidéo Oracle"

Environnement de base de données pour les données de test de cet article : Oracle 11g

Pourquoi est-il dit que c'est SQL lors de l'exécution de la session Il semble que l'exécution de SQL ? l'enregistrement d'une certaine session ne peut pas être obtenu, j'ai également lu de nombreux articles de blog. De nombreuses personnes sur Internet ont dit que l'enregistrement d'exécution SQL d'une certaine session peut être interrogé en associant sql_id à la vue v$active_session_history et v$sqlarea. Après la pratique, il a été constaté que ce n'était pas possible (essayé via la table dba_hist_active_sess_history Cela ne fonctionne pas non plus), le sql_id de certains sql n'est pas du tout enregistré dans v$active_session_history. control_management_pack_access et j'ai constaté que je n'avais pas l'autorisation. Et je l'ai vérifié et j'ai constaté que la valeur du paramètre est normale et que la base de données des paramètres est ouverte, reportez-vous au billet de blog : La requête Oracle V$ACTIVE_SESSION_HISTORY n'a pas de données - wazz_s - Blog Park.

​ L'enregistrement d'exécution de SQL peut être interrogé via la vue v$sqlarea, mais l'ID de session pour l'exécution de SQL est introuvable. Ce serait formidable s'il y avait un tel ID de session, je peux savoir qui a exécuté le SQL. .

Si je souhaite interroger le SQL qui a provoqué le verrouillage de la table, la plupart des articles de blog sur Internet l'enseignent. Obtenez la valeur du champ prev_sql_addr correspondante en interrogeant la vue v$session, enregistrez-la comme valeur A, puis. utilisez la valeur A comme valeur de condition de requête du champ d'adresse dans la vue v$sqlarea, puis l'enregistrement SQL correspondant peut être interrogé. À titre de test pratique, vous pouvez trouver le SQL qui trouve la table de verrouillage, mais dans la plupart des cas, vous ne pouvez pas l'obtenir dans un environnement de production normal. Pourquoi ? Veuillez consulter l'introduction ci-dessous.

Cet article utilise une approche exploratoire pour étudier. Afin de garantir l'exactitude des données, j'ai ouvert trois sessions de base de données, enregistrées comme session1, session2 et session3. Les étapes spécifiques sont les suivantes :

. 1 en session session1 Créer une nouvelle table de test et tester les données

--新建测试表
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 Afficher l'ID de session de la session1

 select userenv('sid') from dual;

Vous pouvez voir que l'ID de session est 2546

3 Dans la session1, verrouillez une ligne du table zxy_table via select for update , comme suit :

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

4 Dans la session2, demandez que l'identifiant de session est 2189 :

Puis dans la session2, mettez à jour la ligne avec la valeur zxy_table zxy_name='zxy1' dans la session2, comme suit :

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

Ensuite, regardez Le sql a été bloqué, comme indiqué ci-dessous :

5 Ensuite, nous arrivons à la session 3 pour vérifier la situation de la table de verrouillage

Vérifiez d'abord la table v$locked_object

select * from v$locked_object;

Vous Vous pouvez voir ce qui a causé le verrouillage de la table. L'ID de session est 2546, qui est la session précédente1, et l'object_id est 110154. Bien sûr, dans l'environnement de génération, vous verrez certainement plus d'un enregistrement. Vous devrez l'exécuter plusieurs fois. Après l'avoir exécuté n fois, vous pouvez toujours voir les enregistrements. , prouvez que cet enregistrement est l'enregistrement de la table de verrouillage

Interrogez les informations détaillées de la table de verrouillage via object_id : 110154 dba4_objects table

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

Interrogez la vue. v$session

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';

via sessionid : 2546 pour obtenir prev_sq l_addr La valeur est : 000000012E045E28, puis interrogez la vue v$sqlarea

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

à partir de la valeur obtenue. l'instruction qui a provoqué le verrouillage de la table, mais de nombreux articles de blog sont terminés à cette étape, donc la requête est vraiment Est-elle fiable ? La réponse n'est pas fiable. Vous pouvez revenir à la session1 et exécuter un sql à volonté, comme suit :

 select * from zxy_table;

Ensuite, vous pouvez l'exécuter dans la session3

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';

.

 再看看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视频教程》

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!