|
|
Oracle Database 21cのオンプレミスリリースが目前となり、その全容が明らかになってきました。
あわせてOracle Databaseは「コンバージド・データベース」として、様々なデータをOracle Databaseでサポートするという展望が発表されています。
このコンバージド・データベースの一角として、Oracle Database 21cではOracleへブロックチェーン（分散型台帳技術）の思想を取り入れたBlockchain Tableという新たなオブジェクトが誕生しました。
今回はOracle Database 19c Release Update 19.10（以降、RU 19.10）でバックポート※された、このBlockchain Tableを検証していこうと思います。
※バックポート...新たなバージョンにて実装された機能を、旧バージョンへ移植すること。
Index
Oracle Databaseには豊富なセキュリティ対策の機能が提供されています。
|
|
データ暗号化オプション「Oracle Advanced Security」、DBAの職務分掌やアクセス制御を実現する「Oracle Database Vault」、監査情報の統合ソリューションである「Oracle Audit Vault and Database Firewall」、データモデリングやマスキングを実現する「Oracle Data Masking and Subsetting」など多種多様です。
今回取り上げるBlockchain Tableは、Oracle Database 21cより標準実装（エディション問わず使用可能）された新たな機能であり、セキュリティの位置づけとしては格納されたデータの改ざんを阻止するためのソリューションとなっています。
Blockchain Tableとは、ブロックチェーン技術の思想を取り入れた新たなテーブルオブジェクトのタイプです。
従来のテーブルと使用方法に大きな差はありませんが、耐改ざん性と証跡性を備えた特殊なテーブルオブジェクトです。
INSERTのみが許可されることに大きな特徴があり、挿入後のデータ変更はオブジェクトのオーナーもSYSDBAのような特権ユーザにも認められないことから、改ざんが事実上不可という特性を備えています。
また、ブロックチェーン技術の特色が大きく出ていると感じる点として、Blockchain Tableに格納される最初の行を除き、以降の全ての行は一つ前の行と暗号化ハッシュを使用して連鎖されています。
このハッシュの連鎖で前後の行をリンクし、データが改ざんされていない整合性を検証および証明することができます。
本編に入る前に、今後のOracle Databaseのリリースモデルについて簡単におさらいをします。
Oracle Database 18c以降のリリースには、Long Term ReleaseとInnovation Releaseの2つのタイプがあります。
|
|
2021年4月20日時点の情報です。掲載情報は変更になる可能性があります。
参考：Release Schedule of Current Database Releases (ドキュメントID 742060.1)
Innovation ReleaseのPremier Supportは2年であり、その後のExtended Supportの提供はありません。
対してLong Term RleaseのPremier Supportは5年、その後のExtended Supportは3年であり、その名の通り長期的なサポートが提供されます。
そのため、Innovation Releaseでは将来のLong Term Rleaseに備えた新規機能のアプリケーション検証などの用途が向いており、Long Term Rleaseは本番システムでの導入事例が多くなることが予想されます。
直近のInnovation ReleaseよりもRU 19.10以上での本番利用が現実的ではと想定し、当記事ではバックポートが提供された19cでの検証に臨みました。
19cでBlockchain Tableを使用するには、いくつかの事前準備が伴います。
本来21cからの新機能であるBlockchain Tableは、19cではバックポートという形で提供されています。
前提としてデータベースソフトウェアのバージョンがRU 19.10以上である必要があります。
加えて、19cで不足しているファイルをPatch 32431413で補うことでBlockchain Tableが作成可能となります。
パッチ（RU 19.10とPatch 32431413）を適用した直後はBlockchain Tableを作成しようとすると、下記のようにORA-05728とORA-00722が発生して失敗してしまいます。
SQL> create blockchain table BC_TAB(col1 number) 2 no drop until 16 days idle 3 no delete locked 4 hashing using "SHA2_512" version "v1"; create blockchain table BC_TAB(col1 number) * 行1でエラーが発生しました。: ORA-05728: COMPATIBLE needs to be 19.10.0.0.0 or higher to use blockchain table ORA-00722: 機能"Blockchain table"
ORA-05728のエラーメッセージの通り、バックポートを有効にするためには初期化パラメータCOMPATIBLEに「19.10.0.0.0」と設定しなくてはなりません。
--初期化パラメータCOMPATIBLEにRUのバージョンを設定する SQL> alter system set compatible='19.10.0.0.0' scope=spfile; システムが変更されました。 --パラメータを反映させるためにインスタンスを再起動する SQL> shutdown immediate データベースがクローズされました。 データベースがディスマウントされました。 ORACLEインスタンスがシャットダウンされました。 SQL> startup ORACLEインスタンスが起動しました。 Total System Global Area 5049940832 bytes Fixed Size 9145184 bytes Variable Size 1040187392 bytes Database Buffers 3992977408 bytes Redo Buffers 7630848 bytes データベースがマウントされました。 データベースがオープンされました。 --PDBへ接続してBlockchain Tableが作成できることを確認 SQL> conn knakagaki/pass@gacky:1521/orcl_pdb.ashisuto.co.jp 接続されました。 SQL> create blockchain table BC_TAB(col1 number) 2 no drop until 16 days idle 3 no delete locked 4 hashing using "SHA2_512" version "v1"; 表が作成されました。
通常はCOMPATIBLEパラメータにRUのバージョンを格納はしません。
| Oracle Databaseのリリース | デフォルト値 | 最小値 | 最大値 |
| Oracle Database 19c | 19.0.0 | 11.2.0 | CDBまたは非CDBインスタンスの場合、RUまたはRURのCOMPATIBLEパラメータを変更しないでください。 |
Oracle® Database データベース・アップグレード・ガイド 19c
Oracle DatabaseのCOMPATIBLE初期化パラメータの値
より引用
RU 19.10以上で提供されているBlockchain Tableのバックポートを利用するために、例外的にRUのバージョンを格納することは認められております。
既知の問題として、COMPATIBLEパラメータにRUのバージョンを格納するとData Pumpユーティリティが使用できなくなってしまう事象が発生します（My Oracle Support Notes 2656508.1
）。
この問題はPatch 30828205を別途適用することで回避可能です。
それではBlockchain Tableを実際に作成し、検証を行っていきましょう。
Blockchain Tableは「CREATE BLOCKCHAIN TABLE」コマンドを使用して作成します。
実際の作成時にはオブジェクトごとに
赤い太字の箇所
を書き換える必要がある点にご注意ください。
CREATE BLOCKCHAIN TABLE
オブジェクト名
(
列定義
)
NO DROP [ UNTIL
n
DAYS IDLE ]
NO DELETE [ UNTIL
n
DAYS AFTER INSERT ] [ LOCKED ]
HASHING USING “SHA2_512” VERSION “v1”;
Blockchain TableはINSERTのみ可能なイミュータブル※なオブジェクトであるという設計思想があります。
そのため、CREATE文ではBlockchain Tableの保存期間と、格納される行データの保存期間を設定します。
※イミュータブル...作成後に変更されない性質のこと。
| NO DROP | Blockchain Tableが削除されない定義です。 |
| NO DROP UNTIL n DAYS IDLE | Blockchain Tableに格納された最新の行データの経過日数がn日未満の場合、削除されない定義です。nの最小値は0です。 なお、作成後に保存期間を短くすることはできません。 |
| NO DELETE [ LOCKED ] | 行データが削除されない定義です。 LOCKEDキーワードを付与すると、保存設定は変更不可となります。 |
| NO DELETE UNTIL n DAYS AFTER INSERT [ LOCKED ] | 行データがn日経過するまで削除されない定義です。nの最小値は16です。 LOCKEDキーワードを付与すると、保存設定は変更不可となります。 なお、作成後に保存期間を短くすることはできません。 |
以下では検証用のオブジェクトとして、格納された最新の行データの経過日数を問わずDROP可能で、行データが16日経過するまで削除されないBlockchain Tableを作成しました。
SQL> create blockchain table BC_TAB(col1 number) 2 no drop until 0 days idle 3 no delete until 16 days after insert locked 4 hashing using "SHA2_512" version "v1"; 表が作成されました。 SQL> select TABLE_NAME,ROW_RETENTION,ROW_RETENTION_LOCKED,TABLE_INACTIVITY_RETENTION 2 from USER_BLOCKCHAIN_TABLES; TABLE_NAME ROW_RETENTION ROW_RETENTION_LOCKED TABLE_INACTIVITY_RETENTION ---------- ------------- -------------------- -------------------------- BC_TAB 16 YES 0
データの登録は通常のテーブルオブジェクトと変わりなく可能です。
試しに1行INSERTしてみます。
SQL> insert into BC_TAB values (12345); 1行が作成されました。 SQL> commit; コミットが完了しました。 SQL> select COL1 from BC_TAB; COL1 ---------- 12345
通常のテーブルと同様にINSERT文でデータが登録でき、SELECT文で問い合わせができました。
通常のテーブルからBlockchain Tableへ利用を切り替える場合、前述のように通常のテーブルと同様にSELECT文での問い合わせが可能なことから、データを移行するのみでアプリケーションからは透過的に利用が可能と考えられます。
例えば、以下のような部屋の入退室記録があり、セキュリティ重要度が高いことからBlockchain Tableへ利用を移行するケースを想定します。
SQL> select ACCESS_DATE,ID,ACTION from ROOM_ACCESS order by 1; ACCESS_DATE ID ACTION ------------------------ ---------- ------------------------------ 21-01-01 04:17:30.174396 9265 EXIT 21-01-01 05:05:04.986174 8390 EXIT 21-01-01 10:18:30.140534 9302 EXIT 21-01-01 13:10:04.190704 6774 ENTER 21-01-01 14:36:30.097022 5595 EXIT 21-01-01 19:05:00.114364 7970 EXIT 21-01-01 19:18:10.217762 6217 ENTER ・・・省略・・・ 21-04-10 00:55:50.038410 1163 EXIT 21-04-10 04:12:28.132694 8398 ENTER 21-04-10 05:14:30.077214 9246 EXIT 21-04-10 06:25:50.000568 2172 EXIT 21-04-10 08:30:30.174714 5653 EXIT 21-04-10 09:38:10.075122 6698 EXIT 21-04-10 12:21:40.033440 4134 EXIT 21-04-10 12:25:40.104282 3615 EXIT 21-04-10 13:41:30.018330 9997 EXIT 21-04-10 18:11:56.981372 885 EXIT 21-04-10 18:18:10.019506 4609 EXIT
アプリケーションから透過的に利用を切り替えることを考慮すると、オブジェクト名は同名であることが望ましいかと思います。
しかし、ディクショナリ上では通常のテーブルもBlockchain TableもOBJECT_TYPE=TABLEとして扱われるため、同名のオブジェクトは作成ができません。
--同名のオブジェクトが存在する旨のエラーを受ける SQL> create blockchain table ROOM_ACCESS 2 (ACCESS_DATE TIMESTAMP(6), 3 ID NUMBER(4,0), 4 ACTION VARCHAR2(10) 5 ) 6 no drop until 0 days idle 7 no delete until 16 days after insert 8 hashing using "SHA2_512" version "v1"; create blockchain table ROOM_ACCESS * 行1でエラーが発生しました。: ORA-00955: すでに使用されているオブジェクト名です。 --USER_OBJECTSビューを参照するとBlockchain TableもOBJECT_TYPE=TABLE SQL> select OBJECT_NAME,OBJECT_TYPE from USER_OBJECTS 2 where OBJECT_NAME='BC_TAB'; OBJECT_NAME OBJECT_TYPE -------------------- -------------------- BC_TAB TABLE
そのため、同名のオブジェクトが必要な場合にはオリジナルのテーブルを一度別のテーブルへ退避した後に、Blockchain Tableを作成する必要があります。
--ROOM_ACCESS表のデータを退避用のテーブルへ格納する SQL> create table ROOM_ACCESS_TEMP as select * from ROOM_ACCESS; 表が作成されました。 SQL> drop table ROOM_ACCESS purge; 表が削除されました。 --ROOM_ACCESSという名前のBlockchain Tableを作成 SQL> create blockchain table ROOM_ACCESS 2 (ACCESS_DATE TIMESTAMP(6), 3 ID NUMBER(4,0), 4 ACTION VARCHAR2(10) 5 ) 6 no drop until 0 days idle 7 no delete until 16 days after insert 8 hashing using "SHA2_512" version "v1"; 表が作成されました。
その後、退避したオリジナルのデータをBlockchain Tableへ移行していきます。
「データの移行」と聞くとData Pumpユーティリティを思い浮かべる方が多いかと思います。残念ながらBlockchain TableではData Pumpユーティリティの制限が多く（Data Pump使用に関する制限はデータベース管理者ガイド
を参照）、table_exists_actionパラメータのAPPEND、TRUNCATE、REPLACEが使用できないため、既存のBlockchain Tableへのデータインポートはできません。
そのため、データを移行するには、INSERT … SELECTで移行するという方法のみが可能であると考えられます。
--退避用のテーブルからBlockchain Tableへデータを登録し直す
SQL> insert into ROOM_ACCESS select * from ROOM_ACCESS_TEMP;
1000行が作成されました。
SQL> commit;
コミットが完了しました。
SQL> select * from ROOM_ACCESS order by 1;
ACCESS_DATE ID ACTION
------------------------ ---------- ------------------------------
21-01-01 04:17:30.174396 9265 EXIT
・・・省略・・・
21-04-10 18:18:10.019506 4609 EXIT
Blockchain Tableがどのようにして高い耐改ざん性を実現しているのか確認していきましょう。
Blockchain Tableはユーザが定義する列と、Oracleが作成する非表示の列から構成されます。
この非表示列にはテーブル内で一意のシーケンスなどが含まれ、前後の行の関係性を暗黙的に記録しています。
内部的にシーケンスが割り当てられるため、最初の1行目を除き全ての行データには一意の前の行が存在することになります。
この前後の行の関係性をBlockchain TableではSHA2-512アルゴリズムによるハッシュ値を算出し、行を連鎖することで高い耐改ざん性を実現しています。
SQL> select COL1, 2 ORABCTAB_CHAIN_ID$, 3 ORABCTAB_SEQ_NUM$, 4 to_timestamp_tz(ORABCTAB_CREATION_TIME$) at time zone 'Asia/Tokyo' "ORABCTAB_CREATION_TIME$", 5 ORABCTAB_HASH$ 6 from BC_TAB order by 4; COL1 ORABCTAB_CHAIN_ID$ ORABCTAB_SEQ_NUM$ ORABCTAB_CREATION_TIME$ ---------- ------------------ ----------------- ---------------------------------------- ORABCTAB_HASH$ --------------------------------------------------------------------------------------------------------------------------------------- 12345 17 1 21-03-14 20:11:25.616573 ASIA/TOKYO 6897669AE1EA23A1327AC1CCB9AC0BE74E27D1CBD3BBDFBD9B55C4DECE7CC7DF51B42F81EEDB6F12C939659411C6E0542C9E1C8479297FF18F7DCDB89BA3DACD 67890 17 2 21-03-14 20:11:25.619577 ASIA/TOKYO 1AA48865D4BCE8F56B478042110A709058959877DC300ADB79E026D7BDAA010F2033BF1CC7B059CB5BF6712DBFDE813EE5080E97072B7EC9115AD75FBE289D24
非表示列についてはデータベース管理者ガイド をご参照ください。
前述の通り、Blockchain TableはINSERTのみ可能なイミュータブルなオブジェクトです。
つまり、挿入後のデータ変更は認められません。
このBlockchain TableへINSERTされた行データが挿入後に変更されていないことを証明するために、DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWSプロシージャ
でデータの整合性を検証することができます。
DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWSプロシージャでは、Blockchain Table内のハッシュ値を再計算して、その値が対応する内部列に保存されている値と一致することを検証し、不正がある場合には該当する例外が表示されます。
SQL> set serveroutput on
SQL> DECLARE
2 verify_rows NUMBER;
3 BEGIN
4 DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS('KNAKAGAKI','BC_TAB', NULL, NULL, 1, NULL, verify_rows);
5 DBMS_OUTPUT.PUT_LINE('Number of rows verified in instance Id '|| 1 || ' = '|| verify_rows);
6 END;
7 /
Number of rows verified in instance Id 1 = 2
PL/SQLプロシージャが正常に完了しました。
高い耐改ざん性を実現する一方で、Blockchain Tableには通常のテーブルと比べて多くの使用上の制限事項があります。
代表的な例としては、挿入後のデータ変更は認められないためINSERTを除くDML操作は受け入れられず、作成後のテーブル定義の変更も行うことはできません。
--UPDATEが実行できない SQL> update BC_TAB set col1=99999 where col1=12345; update BC_TAB set col1=99999 where col1=12345 * 行1でエラーが発生しました。: ORA-05715: operation not allowed on the blockchain table --列定義の変更が行えない SQL> alter table BC_TAB modify (col1 number(10)); alter table BC_TAB modify (col1 number(10)) * 行1でエラーが発生しました。: ORA-05715: operation not allowed on the blockchain table
その他にも制限される操作が多々あるため、データベース管理者ガイド を併せてご確認ください。
Blockchain Tableの作成時に行データの保存期間を定めます。
「NO DELETE UNTIL n DAYS AFTER INSERT」で定義した場合、設定したn日を超えた行データを削除することができます。
ただし、通常のテーブルのようにDELETEコマンドでは削除できない点がBlockchain Tableの特徴です。
--各行のINSERTされた時間を確認する SQL> select COL1,to_timestamp_tz(ORABCTAB_CREATION_TIME$) at time zone 'Asia/Tokyo' "ORABCTAB_CREATION_TIME$" 2 from BC_TAB order by 2; COL1 ORABCTAB_CREATION_TIME$ ---------- ---------------------------------------- 12345 21-03-14 20:11:25.616573 ASIA/TOKYO 67890 21-03-14 20:11:25.619577 ASIA/TOKYO 99999 21-03-15 19:46:44.101890 ASIA/TOKYO SQL> select SYSDATE from DUAL; SYSDATE ----------------- 21-04-11 16:41:51 --現在格納されている行データは何れも保存期間を超過しているが、DELETEコマンドでは削除できない SQL> delete BC_TAB where COL1=12345; delete BC_TAB where COL1=12345 * 行1でエラーが発生しました。: ORA-05715: operation not allowed on the blockchain table
保存期間を超えた行データは、DBMS_BLOCKCHAIN_TABLE.DELETE_EXPIRED_ROWSプロシージャ
を使用して削除します。
下記の例ではbefore_timestampパラメータ（第3引数）より前に挿入されたデータを削除しています。
SQL> set serveroutput on
SQL> DECLARE
2 num_rows NUMBER;
3 BEGIN
4 DBMS_BLOCKCHAIN_TABLE.DELETE_EXPIRED_ROWS('KNAKAGAKI',
5 'BC_TAB',
6 '21-03-14 20:12:00.00 +09:00',
7 num_rows
8 );
9 DBMS_OUTPUT.PUT_LINE('Number_of_rows_deleted=' || num_rows);
10 END;
11 /
Number_of_rows_deleted=2
PL/SQLプロシージャが正常に完了しました。
--before_timestampパラメータより前に挿入されたCOL1=12345と67890の行が削除された
SQL> select COL1,to_timestamp_tz(ORABCTAB_CREATION_TIME$) at time zone 'Asia/Tokyo' "ORABCTAB_CREATION_TIME$"
2 from BC_TAB order by 2;
COL1 ORABCTAB_CREATION_TIME$
---------- ----------------------------------------
99999 21-03-15 19:46:44.101890 ASIA/TOKYO
Blockchain Tableの表定義の変更は基本的に不可ですが、行データの保存期間やBlockchain Tableの保存期間の変更は可能です。
--最新の行データの経過日数が5日未満の場合に表がDROPできず、 行データは16日経過するまで削除されないBlockchain Tableを作成 SQL> create blockchain table BC_TAB(col1 number) 2 no drop until 5 days idle 3 no delete until 16 days after insert 4 hashing using "SHA2_512" version "v1"; 表が作成されました。 SQL> select * from USER_BLOCKCHAIN_TABLES; TABLE_NAME ROW_RETENTION ROW_RETENTION_LOCKED TABLE_INACTIVITY_RETENTION HASH_ALGORITHM ---------- ------------- -------------------- -------------------------- ------------------------ BC_TAB 16 NO 5 SHA2_512 --表のDROPが可能となる最新の行データの経過日数を10日未満へ延長する SQL> alter table BC_TAB no drop until 10 days idle; 表が変更されました。 SQL> select * from USER_BLOCKCHAIN_TABLES; TABLE_NAME ROW_RETENTION ROW_RETENTION_LOCKED TABLE_INACTIVITY_RETENTION HASH_ALGORITHM ---------- ------------- -------------------- -------------------------- ------------------------ BC_TAB 16 NO 10 SHA2_512 --行データが削除可能となる経過日数を20日に延長する SQL> alter table BC_TAB no delete until 20 days after insert; 表が変更されました。 SQL> select * from USER_BLOCKCHAIN_TABLES; TABLE_NAME ROW_RETENTION ROW_RETENTION_LOCKED TABLE_INACTIVITY_RETENTION HASH_ALGORITHM ---------- ------------- -------------------- -------------------------- ------------------------ BC_TAB 20 NO 10 SHA2_512
ただし、保存期間を大きくすることはできますが、短縮することはできないため、Blockchain Tableの作成時や定義の変更時には十分に要件を考慮のうえ作業を実施ください。
ある程度の保持期間で運用検証を行った後に、Blockchain TableをDROPできないように変更するというケースもあるかもしれません。
しかし、現状この操作を行うとORA-00600エラーで処理が失敗してしまう不具合があります（My Oracle Support Notes 2762547.1
）。開発部門での調査中のため、DROP不可なBlockchain Tableを作成したい場合にはCREATE時に指定するようにしてください。
SQL> alter table BC_TAB no drop;
alter table BC_TAB no drop
*
行1でエラーが発生しました。:
ORA-00600: 内部エラー・コード, 引数: [atbbctable_1], [0], [], [], [], [], [], [], [], [], [], []
今回はOracle Database 21cから登場したBlockchain Tableを検証、ご紹介しました。
INSERTのみが許可される、SYSDBAもオブジェクトオーナーでもデータ変更が不可能というデータの堅牢性が担保された、格納されたデータの信頼性が非常に高いオブジェクトです。
オラクル社のセミナーではこのイミュータブルな特性から、
「アプリケーションのアクセスログや監査ログ、
高セキュリティエリアへの入退室記録などセキュリティ上重要な記録」
「企業の会計、財務のデータなど法律上確実な保存が要求される情報」
「勘定系システム、決済系システムなど内外からの攻撃に対して保護すべきデータ」
といったユースケースが紹介されていました。
しかしこの堅牢さから、誤ったデータの混入が万が一起こった場合には対応が難しいオブジェクトである側面もあると考えます。
例えば、「FLASHBACK TABLE」コマンドはオブジェクトの制限上使用できず、バックアップファイルからメディアリカバリを行う必要があるなど、扱ううえでの考慮点は多々あります。
格納されるタイミングのデータの信頼性も確実なものにするためには、もうワンクッション対策が必要である点はシステム構築上の1つの課題となるでしょう。
アシストでは多くの製品を組み合わせてお客様の課題を解決するお手伝いをしています。
データベースのセキュリティ対策もご支援しておりますので、ぜひお気軽にお問い合わせください。
＜参考＞
オラクルエンジニア通信
オラクルのデータベース・セキュリティ全体像：DB基本機能～情報漏洩・不正アクセス防止etc
Blockchain TableによるOracle Databaseのコンバージドデータベースの拡張
|
|---|
アシスト北海道
2016年アシスト北海道へ入社後、Oracle Databaseのサポート業務に従事。入社2年目より夜間休日帯など営業時間外の緊急対応を主に担当。現在は通常時間帯のサポート業務を担当しており、第一線で日々奮闘中。...show more
■本記事の内容について
本記事に記載されている製品およびサービス、定義及び条件は、特段の記載のない限り本記事執筆時点のものであり、予告なく変更になる可能性があります。あらかじめご了承ください。
■商標に関して
・Oracle®、Java及びMySQLは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
本記事では、従来のON COMMIT MViewが抱えてきたこのようなスループット低下や待機イベントのボトルネックを振り返りつつ、Oracle AI Database 26aiが提供する「同時リフレッシュ（Concurrent Refresh）」によって、OLTP／DWHそれぞれのユースケースでどのような改善が見込めるのかを検証していきます。
BaseDBの運用でData Pump用の領域が不足した際、外部ストレージの活用が有効です。本記事では3つのストレージについて1TB利用時のコスト目安や性能、運用負荷を徹底比較します。自社環境に最適な外部ストレージ選びのポイントが分かります。
Oracle Trace File Analyzer（TFA）は、障害時のログ収集を効率化するツールです。複数ログの一括取得や時間指定、シングル環境での導入手順まで、現場目線でわかりやすく解説します。
![[260424T]脱・PostgreSQL運用の不安！EDBのPEM管理術：GUIでの障害特定から監視まで](/db_blog/__icsFiles/afieldfile/2026/03/23/EDB_mail-bannar-260424a_176x250px.png)
