Explication graphique et textuelle détaillée des solutions de table de verrouillage Oracle

Cet article vous apporte des connaissances pertinentes sur Oracle Lors du développement d'une base de données Oracle, nous rencontrons souvent des tables de données Oracle fréquemment utilisées, et nous vous présenterons ici la solution aux tables de verrouillage Oracle. J'espère que ces informations. sur la méthode sera utile à tout le monde.

Tutoriel recommandé : "Tutoriel vidéo Oracle"

Je pense que tout le monde est familier avec le verrouillage de table ou le délai d'attente de verrouillage. Cela se produit souvent dans les instructions DML. La raison en est le mécanisme de blocage exclusif de la base de données. Instruction DML Les données de la table ou de la ligne sont verrouillées jusqu'à ce que la transaction soit validée ou annulée ou que la session en cours soit terminée de force.

Pour notre système d'application, le verrouillage des tables est susceptible de se produire lorsque l'exécution de SQL est lente et qu'il n'y a pas de délai d'attente (un SQL a été exécuté sans succès pour une raison quelconque (l'outil Spoon effectue l'extraction et le push des données) et les ressources n'ont pas été libérées) Par conséquent, écrire du SQL efficace est également particulièrement important ! Il existe d'autres situations dans lesquelles le verrouillage de table peut se produire, ce qui constitue un scénario de concurrence élevée. Le problème causé par une concurrence élevée est que les transactions Spring entraîneront la non validation des transactions de base de données et provoqueront un blocage (la transaction en cours attend que d'autres transactions libèrent les ressources de verrouillage. )! Jetant ainsi l'exception java.sql.SQLException : le délai d'attente du verrouillage est dépassé ;.

Alors, comment résoudre le problème de la table de verrouillage ou du délai d'expiration du verrouillage ? La solution temporaire consiste à rechercher la table ou l'instruction en concurrence pour la ressource de verrouillage, à mettre directement fin à la ou aux sessions en cours et à forcer la libération de la ressource de verrouillage. Par exemple

La solution est la suivante :

1. Session1 modifie une certaine donnée mais ne soumet pas la transaction. Session2 interroge l'enregistrement de la transaction non validée

2.

Nous pouvons voir la modification Les enregistrements des transactions non validées seront dans un état d'attente jusqu'à ce que l'autre partie libère la ressource de verrouillage ou ferme de force la session1. Cela montre également qu'Oracle a réalisé des verrous au niveau des lignes !

Il s'agit simplement d'une simple simulation de la situation de verrouillage de la table. Vous pouvez voir en un coup d'œil qu'il s'agit du verrouillage de la table provoqué par la session1. Lorsqu'on rencontre cette situation dans le développement réel, SQL est généralement utilisé pour rechercher directement les tables ou les instructions qui sont en concurrence pour les ressources de verrouillage, puis libérer de force les ressources ! !

3. Session3 interroge les tables ou les déclarations des ressources concurrentes et force la libération des ressources

-- 查询未提交事务的session信息，注意执行以下SQL，用户需要有DBA权限才行
SELECT
    L.SESSION_ID,
    S.SERIAL#,
    L.LOCKED_MODE AS 锁模式,
    L.ORACLE_USERNAME AS 所有者,
    L.OS_USER_NAME AS 登录系统用户名,
    S.MACHINE AS 系统名,
    S.TERMINAL AS 终端用户名,
    O.OBJECT_NAME AS 被锁表对象名,
    S.LOGON_TIME AS 登录数据库时间
FROM V$LOCKED_OBJECT L
    INNER JOIN ALL_OBJECTS O ON O.OBJECT_ID = L.OBJECT_ID
    INNER JOIN V$SESSION S ON S.SID = L.SESSION_ID
WHERE 1 = 1

Les résultats de la requête sont les suivants

Seuls les deux premiers champs nous sont utiles pour libérer de force les ressources. , après que

-- 强制 结束/kill 锁表会话语法
ALTER SYSTEM KILL SESSION 'SESSION_ID, SERIAL#';

-- 强制杀死session1，让session2可以修改id=5的那条记录
ALTER SYSTEM KILL SESSION '34, 111';

tue de force la session1, faites attention à l'exécution de la session2 ! Nous constaterons que l'attente de la session2 sera terminée et exécutée immédiatement ! Je crois que tout le monde a un doute, session_id est 29 et 34, comment déterminer s'ils appartiennent à session1 ou session2, et s'assurer que session1 est tuée et que session2 peut exécuter avec succès l'instruction DML ?

En fait, c'est très simple. La méthode de jugement ici est l'exécution de session1. Pour mettre à jour mais ne pas valider la transaction, vous pouvez d'abord utiliser le SQL ci-dessus pour interroger les informations de session de la transaction non validée. Les informations trouvées à ce moment sont les informations de session1.

Tutoriel recommandé : "

Tutoriel vidéo 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!