DLPソリューションでのDBMSの使用の詳細は、データ量が非常に急速に増加することです。 それらを運用アーカイブに保管することは不可能であり、少なくとも50人のスタッフを抱える企業にとっては、長期保管が必要です。 同時に、オンラインアーカイブはすぐにいっぱいになるため、2週間に1回またはそれ以上の頻度で情報を長期アーカイブに送信する必要があります。 組み込みのDBMSツールのみを使用するには、知識と経験が必要です。 これが主な難点であり、一般的に、「海岸で」明白です。
さらに、すぐには明らかではない問題が発生します。 長期アーカイブからアプリケーションの古いバージョンのデータを含むパーティションを返し、それをより新しいアーカイブにアタッチする方法は？ 異なるデータストレージ形式がある場合はどうなりますか？ セクションへの接続が中断され、長期アーカイブとオンラインアーカイブの間で「ハング」した場合はどうなりますか？
一般に、これらの問題の解決策は、Oracle DBMSのセクション管理の自動化（切断および接続）と、接続中に問題が発生した場合の「ロールバック」システムの2つの主要な技術タスクに要約されます。
Oracle DBの組み込みメカニズムの何が問題になっていますか
[パーティショニング]オプションは、テープ上のデータを削除し、長期アーカイブからデータを返すのに役立ちます。たとえば、日付の範囲など、何らかの原則に従ってテーブルを部分に分割できます。 管理性と可用性に加えて、この分離により生産性も向上します。 各期間は個別の表スペースに格納されます。これにより、トランスポータブル表スペーステクノロジーを使用して、異なるバージョンおよびプラットフォームの異なるレポートデータベースとアーカイブデータベース間で表スペースをすばやく移動できます。 しかし問題は、標準のメカニズムだけでは十分ではないということです。アプリケーションの詳細を考慮せずに、基本的な構造を作成することしかできません。 そして、管理者はそれらの周りに多数の管理ツールを作成することを余儀なくされます。 また、切断接続転送プロセス自体には、データベース管理スキルが必要です。 したがって、最小限のタスクは、このプロセスを自動化し、アプリケーション管理者がアクセスできるようにすることです。
パーティションテーブルを管理したり、テーブルに関する情報を取得したりできるスクリプトのセットを開発しました。 チームの知識、DBMSの経験は不要です。 アプリケーション管理者は、単にスクリプトを実行するか、インターフェイスで目的のアクションを選択し、目的のパーティションを示します。すべてが自動的に行われます。
（非）バージョンの互換性
そのため、セクションの切断を自動化し、長期アーカイブに送信しました。 ただし、長期アーカイブには問題があります。返される必要がある場合があります。
管理者が古いバージョンのいくつかのセクションをそこに移動したとしましょう。 1年後、新しいバージョンがリリースされ、新しいフィールドがテーブルに追加され、新しいインデックスが作成され、いくつかのセクションが長期アーカイブに残されました。 そして、警備員は特定の事件を調査し、2年前にデータを上げる必要があります。 セクションをいくつかのバージョンに戻し、何らかの形でデータベースに接続します。
新しいバージョンのテーブル構造は、歴史的なものとは異なる場合があります。 アーカイブセクションには、多くのチェックと変更が必要です。 検証は常に、現在のバージョンのSolar DozorとDBMSのバージョン、および接続されているパーティションを比較することから始まります。 違いがある場合、メタデータを修正する手順が開始され、必要なフィールド、インデックス、キーが追加され、接続されたデータの一貫性がチェックされます。
Solar Dozorの検索にテキストインデックスを使用すると、さらに複雑になります。 DBMSの異なるバージョンで作成されたテキストインデックスのEXCHANGE PARTITIONに関連するバグや、トランスポータブルテーブルスペースを使用している場合（バージョン12までのインデックスメタデータの破損）のバグがあります。 パッチは、目的のバージョンまたはプラットフォームに常に利用できるとは限りません。 接続でのインデックスの再作成は、迅速で非常にリソースを消費する手順ではありません。 パーティションを接続する手順に回避策を「プッシュ」する必要がありました。 接続されたパーティションのテキストインデックスのDR $テーブルの構造は、現在のパーティションと「整合」し、テーブルフィールドctxsys.dr $インデックスが更新されます。
管理者のさまざまなエラーに対する保護もあります。 たとえば、アプリケーションレベルでは、現在データが投入されているパーティションのステータスが「現在」のアクションは禁止されています。
「ヒューストン、問題があります」
これらのメカニズムの実装中に、お客様の間で予想外に頻繁に発生する別の問題に遭遇しました。 シャットダウン中は、通常の電気のシャットダウンまで何かがおかしくなり、接続セクションがいつでも中断される可能性があります。 その結果、「中間」状態にあるベースを取得します。
Oracle DBMSにはDDLとDMLがあります。 DMLは、トランザクションの整合性を確保するためのメカニズムを実装し、トランザクションが失敗した場合に結果をロールバックします。 DDLにはそのようなメカニズムはなく、セクションを使用したアクションは一方向のパスです。
パーティションの切断と接続のすべてのステップの完了を確認し、発生した問題を修正するメカニズムを開発しました。 問題が発生した場合、メカニズムは何かがうまくいかなかった瞬間からパーティション操作を再開します。 切断接続中のエラーはログに記録されるため、いつどのような問題が発生したかをいつでも確認できます。
パーティションを無効にするにはどうすればよいですか？ コマンドのシーケンスが作成されます-外部キーが無効化され、無効化されているパーティションと同じ構造のテーブルが作成され、必要なインデックスとプライマリキー、パーティション交換コマンド、外部キーの包含が作成されます。 各コマンドは、実行時にサービステーブルに記録され、キャンセル操作が記録されます（制約の無効化-制約の有効化、テーブルの作成-テーブルの削除など）、操作が実行された時間、操作のステータス。 何らかの問題が発生した場合、手順を再起動した後、シャットダウンが停止したステップでチェックが実行され、次のコマンドが実行されるかロールバックが発生します。記録されたキャンセル操作は逆の順序で実行されます。
| ID
| 声明
| 元に戻す
| ステータス
|
| 4411
| CREATE TABLE ADDRESS2_P10001 TABLESPACE DOZOR1_INDEXES AS SELECT * FROM ADDRESS2 WHERE 1 = 2
| DROP TABLE ADDRESS2_P10001
| わかった
|
| 4412
| CREATE INDEX IX_ADDRESS2_MESSAGE_P10001 ON ADDRESS2_P10001（MESSAGE）TABLESPACE DOZOR1_INDEXES
| NULL
| わかった
|
| 4413
| ADDRESS2_P10001でUNIQUE INDEX IX_ADDRESS2_UNIQ2_P10001を作成（ADDR_TYPE、VALUE、MESSAGE）TABLESPACE DOZOR1_INDEXES
| NULL
| わかった
|
| 4414
| ALTER ADDRESS2 EXCHANGE PARTITION p10001 WITH TABLE ADDRESS2_P10001 WITH INCLUDING WITH IN VALIDATION
| ALTER ADDRESS2 EXCHANGE PARTITION p10001 WITH TABLE ADDRESS2_P10001 WITH INCLUDING WITH IN VALIDATION
| わかった
|
その結果、データベースの初期状態を取得するか、シャットダウン手順が正常に完了します。