Clever Geek Handbook

OracleデータベースでのエディションベースのRedefinitonの2年間の成功した使用

データベースに保存されたコード？ 言うなよ、2017ヤードで！



今年、QIWIブランドは10年目です。 この間に、保存されたPL / SQLコードの13万行以上がメイントランザクションデータベースに蓄積されました。 Habréには、さまざまな開発チームがデータベースに保存されたコードをカテゴリ別に使用せず、データベースから不要な負荷を取り除き、システムのコストを削減しようとする方法に関する記事が定期的にあります。 このトピックについては長い間議論できますが、この観点は、たとえばこのビデオで論議されています 。



議論の余地のないもの-格納されたPL / SQLコードには、従来、重大なマイナス点が1つありました.PL / SQLプログラムのリリースには、サービスを停止する必要がありました。このコードのコンパイルでは、データベースディクショナリ（いわゆるライブラリキャッシュピン ）で排他ロックを取得する必要があったためです。 すぐにトリガーされたランダム再コンパイルは、システム全体を中断する可能性があります。 PL / SQLコードのリリースのために、技術的なウィンドウを定期的に選択する必要がありました。 そのような窓から落ちたinしているクライアントの苦情の認証されたスクリーンショットは、アーカイブに慎重に保存されます。 ただし、PL / SQLの作成から20年未満が経過しています。Oracleがこれを完全に排除しない場合、大幅に軽減されます。



Oracle Editionベースの再定義へようこそ



エディションベースの再定義を使用した詳細なコード例は提供しませんが、実装のプロジェクトのいくつかの重要なポイントについて説明します。 ある程度のストレッチを行うと、このメカニズムは通常EBRに縮小されますが、データベース自体の内部のデータベースオブジェクトのバージョン管理システムと見なすことができます。 これで、アプリケーションは同じプロシージャ、パッケージ、およびビューの異なるバージョンで動作できます。 ただし、データベースには、コードに加えて、テーブル形式のデータ構造もあり、Oracleはテーブル自体とテーブル内のデータの両方を変換変換する方法を考案する必要がありました。



開発者はEBRをビューとPL / SQLコードにのみ使用し、テーブルには使用しないことをすぐに予約します。 サブジェクト領域はよく研究されており、データ構造は非常に安定しています。 1年の間に、ホットテーブルの列は約5回強制的に変更または追加されましたが、コードの変更は数十倍でした。



アプリ



Javaアプリケーションは、PL / SQLコード自体の新しいバージョンを使用するように切り替えることができます。 現在のエディションは、次のような簡単なリクエストでデータベースから抽出できます。 



select property_value from database_properties where property_name = 'DEFAULT_EDITION'


アプリケーションはこの値を保存し、定期的にデータベースをポーリングして、変更されたかどうかを確認します。



PL / SQLコードの新しいバージョンが正常にリリースされると、次の形式のコマンドが実行されます 



 alter database default edition = ED_1180_23185307


エディションが変更されたことを知ったアプリケーションは、適切なタイミングで次の形式のコマンドを実行します。 



 alter session set edition = ED_1180_23185307
その結果、保存されたコードの新しいバージョンの使用に切り替わります。



理論的には、PL / SQLコードを以前のバージョンにロールバックすることができます。これを行うには、以前のエディションがインストールされている状態でalter databaseコマンドを実行します 。



虫



内部のOracle DBMSは非常に複雑であるため、その最適化と開発に多くの人的年月が費やされており、コアの新しい機能が残りの機能に苦労することはありません。 もちろん、バグとそれを修正するパッチについて話します。 EBRはまったく例外ではありませんでしたが、反対に重大なトラブルメーカーでした。 ただ言ってみましょう：テクニカルサポートなしで行うことは不可能です。



残念ながら、OracleはEBR関連のバグを修正するパッチの個別のリストを保持していません。 ただし、オラクルは、人気のあるERPシステムの1つであるOracle E-Business Suite（OEBS）でEBRを積極的に使用しています。 したがって、OEBSベースにインストールすることを推奨するパッチのセットを取得し、アプリケーションに潜在的に最も可能性の高いパッチをベースにインストールできます。 OracleサポートサイトのOracle E-Business Suiteリリース12.2のセクション3：パッチおよびテクノロジーバグ修正の統合リスト（Doc ID 1594274.1）で見つけることができます。



落とし穴



Oracle Edition-Based Redefinitionを使用して作業すると、4つの欠点が見つかりました。



  1. エディションの数の制限は2000です。週に2回のリリースの割合で、20年でそれらを使い果たします。 それまでに、Oracleがこの制限を削除できることを願っています。
  2. ツリー構造エディションではなくフラット、1つの親<–> 1つの子。 これはまだ気にしません。
  3. 非編集オブジェクトはバージョン管理されたオブジェクトを参照できません（たとえば、バージョン11gでは、マテリアライズドビューなどのオブジェクトは非編集オブジェクトであり、編集ビューを参照できません）。
  4. バージョン管理されたコードに対する権利の配布の特異性。


この効果は非常に不十分に説明されているので、私は最後の点についてさらに詳しく説明したいと思います。



事実は、以前の版で最後に変更されたバージョン付きオブジェクトへの権利の発行は、このオブジェクトを現在の版にコピーし、再コンパイルのすべての症状がすでに私たちに馴染み、幸運ではないが、辞書ロックライブラリキャッシュピンでフリーズすることです。 どうやら、これはデータベース内の編集されたスキーマの内部実装によるものです。



したがって、権利を配布する手順を少し変更する必要がありました。まず、目的のオブジェクトが最後に変更されたエディションを見つけ、上記のalter sessionコマンドを使用してこのエディションをセッションにインストールし、その後に必要な権利を発行します。



彼らが言うように、バグ26654363ではなく、予想される動作です。 回避策は労働集約的ではありませんが、ほとんどの場合、うまくいくことができます。



プロジェクトの結果：マイナス16時間の年間計画ダウンタイム



99.8％-> 99.98％



PS DBAとデータベース開発者を探しています！



More articles:


All Articles