October 2017

  目的 このページの目的は、リレーショナル・データベースのデッドロックを特定して対処する方法について説明します。 概要 「デッドロック」とうい用語は、「サイクル・デッドロック」と呼ばれる状況を指しています。2つ以上の競合するトランザクションが同じリソース（通常、テーブルやローのロック）上で相互にブロックしているため、どのトランザクションも処理を進行できなくなり、サーバ側でいずれかのトランザクションを強制的に終了する必要がある状況です。 データベースのデッドロックを解決する方法として、状況に応じて2つの異なるアプローチが考えられます。それぞれのアプローチは、入手可能な情報、対応する側の経験または、嗜好に基づいています。データベース・スキーマの修正を好む管理者もいれば、SQLコードやサーバ／接続オプションの変更を優先する管理者もいます。 デッドロックの難しい点は、テスト環境やQA環境ではほとんど発生せず、開発サイクルの早期に発見することが困難であるということです。通常、デバッグは困難であり、状況によっては、コードの修正もできません。 データベースのデッドロックを回避するために、いくつかのことが必要です。 ・デッドロック情報をログに記録する ・関連するSQLの識別 ・パフォーマンスのためにクエリが最適化されていることを確認 ・トランザクションを短くする ・一般的なパフォーマンスを改訂する デッドロックは、データベース設計及び、SQLコーディングの貧弱さまたは、システムに隠れているその他の問題の症状であることを覚えておくことが重要です。 このドキュメントの例では、SQL Anywhereをデータベース・サーバとして使用していますが、基本的には、SAP HANA、SAP ASE、SAP IQ、Microsoft SQL Server、Oracleなどのその他のリレーショナル・データベース・システムにも同様の手法を適用できます。 アプリケーションがデッドロックの影響を受けているかどうか確認する方法 デッドロックは、散発的（一度起こった後、再び繰り返される）または、反復的（一日の特定の時間に、または特定のレポート/プロシージャ・コールの処理時）に発生する可能性があります。 データベース管理者は、無視するものと注意を払うものか判断する必要があります。 デッドロックが発生する理由は、アプリケーションとデータベース設計に絞り込むことが重要なポイントです。 アプリケーションが異常な動作をしている場合は、ほとんどの場合、処理が正常に実行されているが、何も変更されていないにもかかわらずトランザクションがロールバックされたり、スクリプト処理が失敗したり、アプリケーションから直接、次のエラーが返される場合： SQLCODE=-306, ODBC 3 State=”40001″ 簡単な分析を実行し、デッドロックの原因をデータベースで検証します。 デッドロック情報のロギング SAP SQL Anywhereには、ユーザがデッドロックを解決する上で必要な情報を入手できるデッドロック・ロギング機能があります。デッドロック・ロギング機能は、デフォルトでは有効になっていません。この機能を有効にするには、管理者がSybase