|
|
この記事は、JPOUG Advent Calendar 2025 の8日目の記事です。
昨今、企業のデータガバナンス強化やコンプライアンス対応は、喫緊の課題の一つと言えます。
デジタル化が進むほど「そのデータが本当に正しいのか」「第三者によって改ざんされていないか」を技術的に証明することが、ビジネスの信頼の基盤となります。
Oracle Database 21cから登場したBlockchain Table（以下、ブロックチェーン表）は、まさにこの課題に応えるための堅牢なセキュリティソリューションです。
しかし、ブロックチェーン表はその堅牢性とのトレードオフとして仕様上の制限が多いため、変化の速いビジネス要件への柔軟な対応が難しく、導入の障壁となってしまっていたと筆者は考えます。
今回、Oracle AI Database 26ai（以下、26ai）でBlockchain TableのV2（バージョン2）が実装されました。
このV2は、堅牢なガバナンスと開発・運用の柔軟性という相反する課題を両立させるものであり、上記で述べた障壁を取り除くことでデータガバナンスやセキュリティを向上させるものです。
従来のブロックチェーン表がどのようにアップデートされたのか、弊社で行った動作検証を踏まえて解説していきます。
Index
改めてブロックチェーン表の概要を振り返っていきましょう。
ブロックチェーン表とは、ブロックチェーン（分散型台帳技術）の思想を取り入れたテーブルオブジェクトのタイプです。
これは21cから実装され、19cではRU 19.10以降のリリースでバックポートされています。
耐改ざん性と証跡性を備えた特殊なテーブルオブジェクトであり、作成後はINSERTのみが許可され、一度挿入されたデータの変更は認められません。
データの改ざんが事実上不可能であるという、この堅牢性が特徴として挙げられます。
そしてブロックチェーン技術の特色が色濃く反映されている側面として、格納される最初の行を除き、以降に挿入される全ての行がひとつ前の行と暗号化ハッシュによって連鎖されているという点があります。
このハッシュの連鎖によって、データが改ざんされていないという整合性を検証し証明できます。
ブロックチェーン表は前述のように、格納されたデータの改ざんを徹底的に阻止するというセキュリティ分野における有用なソリューションですが、本番システムに実装するうえでは仕様上の制限も多く、扱いが難しい実情もあります。
代表的な制限事項として、挿入後のデータ変更が認められないためINSERTを除く更新処理ができない点や、作成後のテーブル定義の変更が行えないという制限事項がありました。
--UPDATEを実行しようとするとエラーを受ける SQL> update BC_TAB set COL1=12345 where COL1=11111; update BC_TAB set COL1=12345 where COL1=11111 * 行1でエラーが発生しました。: ORA-05715: 操作はブロックチェーンまたは不変表では許可されていません ヘルプ: https://docs.oracle.com/error-help/db/ora-05715/ --列を追加しようとすると同様にエラーを受ける SQL> alter table BC_TAB add (COL2 varchar2(100)); alter table BC_TAB add (COL2 varchar2(100)) * 行1でエラーが発生しました。: ORA-05715: 操作はブロックチェーンまたは不変表では許可されていません ヘルプ: https://docs.oracle.com/error-help/db/ora-05715/
26aiからブロックチェーン表がバージョンアップし、V2が登場しました。
※厳密には23aiのアップデートとして発表されましたが、My Oracle Support『Document 742060.1
』より23aiは26aiに記載が置き換えられたため、本稿では26aiのアップデートとして紹介します。
このバージョンアップにより、従来のブロックチェーン表（V1、バージョン1）が直面していた仕様上の制限を実質的に緩和でき、ユーザビリティが向上したと言えます。
具体的にはV2では次の機能拡張がされました。
次に検証例を踏まえて、それぞれの機能動作を解説していきます。
V2で実装された上述の3つの機能拡張、加えて新たに追加された初期化パラメータBLOCKCHAIN_TABLE_RETENTION_THRESHOLDについて動作検証を実施しました。
今回は、Oracle AI World 2025 で発表されたOracle AI Database 26aiのFree版で検証に臨みました。
SQL> select BANNER_FULL from V$VERSION; BANNER_FULL ------------------------------------------------------------------------------------- Oracle AI Database 26ai Free Release 23.26.0.0.0 - Develop, Learn, and Run for Free Version 23.26.0.0.0
以下にそれぞれの機能ごとに検証例を提示します。
まず、V2ブロックチェーン表の作成手順から確認していきましょう。
V2もV1と同様に「CREATE BLOCKCHAIN TABLE」コマンドを使用して作成します。
21cで初めてブロックチェーン表が実装された際、VERSION句は”V1”で決め打ちでしたが、26aiからは”V1”または”V2”を指定できるため、V2ブロックチェーン表を作成するためには”V2”を指定してください。
CREATE BLOCKCHAIN TABLE オブジェクト名 ( 列定義 )
NO DROP [ UNTIL n DAYS IDLE]
NO DELETE [ UNTIL n DAYS AFTER INSERT ] [ LOCKED ]
HASHING USING “SHA2_512” VERSION “V2”;
各句の用法については、こちらの記事の『Blockchain Tableの作成』項 を参考にしてください。
次の例では、格納された最新の行データの経過日数が8日未満の場合テーブルをDROPできず、行データが16日経過するまでDELETEできないV2ブロックチェーン表を作成しています。
SQL> create BLOCKCHAIN TABLE BC_TAB_V2 (COL1 number) 2 no drop UNTIL 8 DAYS IDLE 3 no delete UNTIL 16 DAYS AFTER INSERT locked 4 hashing using "SHA2_512" version "V2"; 表が作成されました。 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_V2 16 YES 8
ブロックチェーン表の制限上INSERT以外の更新処理は許可されないため、既存のデータを更新できません。
V2ブロックチェーン表では行バージョン機能が実装され、「ROW VERSION」句で指定した列に同値が格納されると行の新たなバージョンとして認識されます。
この機能により、行データを追加することでUPDATE相当の更新が可能になりました。
以下では、製造業やサプライチェーンのシステム（今回は仮に自動車メーカー「A社」とします）を想定して、BOM（製品の部品構成表）のバージョン管理をブロックチェーン表で実装するイメージで検証してみました。
まずは簡易的なBOMをブロックチェーン表で作成します。
行バージョンには「RV_PRODUCT_PART」と命名し、同一の製品IDと部品IDに対してデータが追加されたときにバージョンが管理されます。
SQL> create BLOCKCHAIN TABLE PRODUCT_BOM 2 (PRODUCT_ID number not null, 3 PART_ID number not null, 4 SUPPLIER_ID number not null, 5 EFFECTIVE_DATE date not null, 6 constraint FK_PRODUCT 7 foreign key (PRODUCT_ID) references PRODUCTS(PRODUCT_ID), 8 constraint FK_PART 9 foreign key (PART_ID) references PARTS(PART_ID), 10 constraint FK_SUPPLIER 11 foreign key (SUPPLIER_ID) references SUPPLIERS(SUPPLIER_ID)) 12 no drop UNTIL 8 DAYS IDLE 13 no delete UNTIL 16 DAYS AFTER INSERT 14 hashing using "SHA2_512" 15 WITH ROW VERSION RV_PRODUCT_PART (PRODUCT_ID, PART_ID) VERSION "V2"; 表が作成されました。
このPRODUCT_BOM表に「製品ID 101にサプライヤーID 900の部品ID 5501を使用する」というデータが2023年10月1日に登録されていたとしましょう。
SQL> insert into PRODUCT_BOM values (101, 5501, 900, DATE '2023-10-01'); 1行が作成されました。 SQL> commit; コミットが完了しました。
A社ではこの他に、製品マスタや部品マスタが存在します。
これらのマスタを結合すると、次のように「MODEL-Ashisuto」という自動車に「アシスト社製のブレーキパッド」が使用されています。
SQL> select p.PRODUCT_NAME,prt.PART_NAME,s.SUPPLIER_NAME,bom.EFFECTIVE_DATE 2 from PRODUCT_BOM bom 3 join PRODUCTS p on bom.PRODUCT_ID = p.PRODUCT_ID 4 join PARTS prt on bom.PART_ID = prt.PART_ID 5 join SUPPLIERS s on bom.SUPPLIER_ID = s.SUPPLIER_ID 6 where bom.PRODUCT_ID = 101; PRODUCT_NAME PART_NAME SUPPLIER_NAME EFFECTIVE_DATE -------------------- -------------------- -------------------- --------------- MODEL-Ashisuto Brake Pad Set K.K.Ashisuto 23-10-01
その後、MODEL-Ashisutoのマイナーチェンジに伴い、ブレーキパッド部品のサプライヤーを変更して改良品に切り替えたとしましょう。
通常であれば既存行のUPDATEを行うシーンですが、ブロックチェーン表ではUPDATEが不可ですので、ここで「製品ID 101の部品ID 5501はサプライヤーID 901製のものを使用する」データをINSERTで追加します。
SQL> insert into PRODUCT_BOM values (101, 5501, 901, DATE '2025-10-25'); 1行が作成されました。 SQL> commit; コミットが完了しました。 SQL> select p.PRODUCT_NAME,prt.PART_NAME,s.SUPPLIER_NAME,bom.EFFECTIVE_DATE 2 from PRODUCT_BOM bom 3 join PRODUCTS p on bom.PRODUCT_ID = p.PRODUCT_ID 4 join PARTS prt on bom.PART_ID = prt.PART_ID 5 join SUPPLIERS s on bom.SUPPLIER_ID = s.SUPPLIER_ID 6 where bom.PRODUCT_ID = 101 order by EFFECTIVE_DATE; PRODUCT_NAME PART_NAME SUPPLIER_NAME EFFECTIVE_DATE -------------------- -------------------- ------------------------------ --------------- MODEL-Ashisuto Brake Pad Set K.K.Ashisuto 23-10-01 MODEL-Ashisuto Brake Pad Set Ashisuto Hokkaido Corp. 25-10-25
この時、製品IDを登録する「PRODUCT_ID」と部品IDの「PART_ID」に同値のデータが登録されたため、行バージョンが管理されます。
ブロックチェーン表には多くの非表示列
が存在し、行バージョンは「ORABCTAB_ROW_VERSION$」にて表されます。
次の例では、サプライヤーID（SUPPLIER_ID）と行バージョン（ORABCTAB_ROW_VERSION$）を見てみましょう。サプライヤーIDが「900」の行バージョンは「1」、サプライヤーIDが「901」の行バージョンは「2」となっています。行バージョンの値が最も大きい行が最新データなので、サプライヤーIDが「901」の行が最新のデータであることがわかります。
このように、製品仕様が変更されたときに過去に採用されていたデータをアーカイブし、最新の行バージョンをアクティブなバージョンとして保持できるのです。
SQL> select PRODUCT_ID,PART_ID,SUPPLIER_ID,EFFECTIVE_DATE,ORABCTAB_ROW_VERSION$ 2 from PRODUCT_BOM 3 where PRODUCT_ID = 101 and PART_ID = 5501 4 order by ORABCTAB_ROW_VERSION$; PRODUCT_ID PART_ID SUPPLIER_ID EFFECTIVE_DATE ORABCTAB_ROW_VERSION$ ---------- ---------- ----------- --------------- --------------------- 101 5501 900 23-10-01 1 101 5501 901 25-10-25 2
なお、行バージョンを伴うV2ブロックチェーン表には「Blockchain_Table_Name_LAST$」という命名規則のビューが作成されます。
これはそのブロックチェーン表の同じ列をSELECTするビューですが、バージョンが管理されている行については最新のバージョンのみを返すクエリです。
例えばこのビューを使って前述の製品マスタと結合することで、最新の製品仕様を確認できます。
SQL> select p.PRODUCT_NAME,prt.PART_NAME,s.SUPPLIER_NAME,bom.EFFECTIVE_DATE 2 from &BC_TAB_NAME._LAST$ bom 3 join PRODUCTS p on bom.PRODUCT_ID = p.PRODUCT_ID 4 join PARTS prt on bom.PART_ID = prt.PART_ID 5 join SUPPLIERS s on bom.SUPPLIER_ID = s.SUPPLIER_ID 6 where bom.PRODUCT_ID = 101 order by EFFECTIVE_DATE; bc_tab_nameに値を入力してください: PRODUCT_BOM 旧 2: from &BC_TAB_NAME._LAST$ bom 新 2: from PRODUCT_BOM_LAST$ bom PRODUCT_NAME PART_NAME SUPPLIER_NAME EFFECTIVE_DATE -------------------- -------------------- ------------------------------ --------------- MODEL-Ashisuto Brake Pad Set Ashisuto Hokkaido Corp. 25-10-25
ブロックチェーン表の強固な耐改ざん性は、ひとつ前の行と暗号化ハッシュで連鎖するシステム・チェーンから実現されています。
V2ブロックチェーン表では、このシステム・チェーンに加えてユーザーが定義する列に暗号化ハッシュを連鎖する「ユーザー・チェーン」を作成できます。
データの整合性を検証する際、従来のV1ではテーブル上のすべての行へアクセスし、システム・チェーンを検証する必要がありました。
このシステム・チェーンとは別に、ユーザーが定義した行のグループに暗号化ハッシュを連鎖させ、ユーザー・チェーンに対する整合性の検証も行えるようになりました。
ユーザー・チェーンは先述した「行バージョン」機能を拡張して実装されています。
そのため、ユーザー・チェーンを利用するためには、行バージョンもあわせて使うことが必要です。
先ほどのA社のBOMにユーザー・チェーンも追加して検証してみましょう。
ユーザー・チェーンは「USER CHAIN」句を用いて行バージョンを作成すると、あわせて作成されます。
SQL> create BLOCKCHAIN TABLE PRODUCT_BOM 2 (PRODUCT_ID number not null, 3 PART_ID number not null, 4 SUPPLIER_ID number not null, 5 EFFECTIVE_DATE date not null, 6 constraint FK_PRODUCT 7 foreign key (PRODUCT_ID) references PRODUCTS(PRODUCT_ID), 8 constraint FK_PART 9 foreign key (PART_ID) references PARTS(PART_ID), 10 constraint FK_SUPPLIER 11 foreign key (SUPPLIER_ID) references SUPPLIERS(SUPPLIER_ID)) 12 no drop UNTIL 8 DAYS IDLE 13 no delete UNTIL 16 DAYS AFTER INSERT 14 hashing using "SHA2_512" 15 WITH ROW VERSION AND USER CHAIN RV_PRODUCT_PART (PRODUCT_ID, PART_ID) 16 VERSION "V2"; 表が作成されました。
データも同様にPRODUCT_IDとPART_IDが同値の行を2行挿入します。
これにより行バージョンの管理に加えて、ユーザー・ハッシュ（非表示列のORABCTAB_USER_CHAIN_HASH$）が生成されます。
SQL> select PRODUCT_ID,PART_ID,SUPPLIER_ID,EFFECTIVE_DATE,ORABCTAB_ROW_VERSION$,ORABCTAB_USER_CHAIN_HASH$ 2 from PRODUCT_BOM 3 where PRODUCT_ID = 101 and PART_ID = 5501 4 order by ORABCTAB_ROW_VERSION$; PRODUCT_ID PART_ID SUPPLIER_ID EFFECTIVE_DATE ORABCTAB_ROW_VERSION$ ---------- ---------- ----------- --------------- --------------------- ORABCTAB_USER_CHAIN_HASH$ ---------------------------------------------------------------------------------------------------------------------------------- 101 5501 900 23-10-01 1 C67B0B959A1250FE92C019B2A40078405E2BE8A851DA72A8BFD3A09C4263319915A0E4E84DFE5D6357C635D3421B7A06FA5767D881A1BA85E661C5F504CF492F 101 5501 901 25-10-25 2 F3192AC1B7270DC6B908F5911ED15CD67DABDA45F5DCC9D0F44DC62FE3756FB1EAF023B216FE6E958DDB8D4E2947668A437171BA5718390940069FD110ADC6A2
生成されたユーザー・チェーンの暗号化ハッシュとデータの整合性を検証するには、DBMS_BLOCKCHAIN_TABLEパッケージのVERIFY_USER_BLOCKCHAIN_ROWSプロシージャ から行います。
SQL> set serveroutput ON SQL> DECLARE 2 verify_rows NUMBER; 3 BEGIN 4 DBMS_BLOCKCHAIN_TABLE.VERIFY_USER_BLOCKCHAIN_ROWS('KNAKAGAKI','PRODUCT_BOM','RV_PRODUCT_PART',verify_rows,101,5501); 5 DBMS_OUTPUT.PUT_LINE('Number of rows verified = ' || verify_rows); 6 END; 7 / Number of rows verified = 2 PL/SQLプロシージャが正常に完了しました。
先の説明のとおりV1のブロックチェーン表では、DMLによる更新もさることながら、表の定義を変更するDDLの実行も不可でした。
しかし、V2ブロックチェーン表では、DDLの中でも「列の追加と削除」のオペレーションが可能となりました。
これにより、運用開始後の要件変更にも対応できる柔軟性がブロックチェーン表に加わりました。
まず、列の追加を試します。
A社のPRODUCT_BOMについて、内部監査部門から「なぜサプライヤーを変更したのか」「誰がその変更を承認したのか」という情報を記録するよう要請があったシナリオを想定し、CHANGE_REASON（変更理由）列とAPPROVED_BY（承認者）列を追加します。
SQL> desc PRODUCT_BOM 名前 NULL? 型 ----------------------------------------- -------- ---------------------------- PRODUCT_ID NOT NULL NUMBER PART_ID NOT NULL NUMBER SUPPLIER_ID NOT NULL NUMBER EFFECTIVE_DATE NOT NULL DATE SQL> alter table PRODUCT_BOM add 2 (CHANGE_REASON varchar2(200), 3 APPROVED_BY varchar2(50)); 表が変更されました。 SQL> select TABLE_NAME,COLUMN_NAME,DATA_TYPE,HIDDEN_COLUMN 2 from USER_TAB_COLS 3 where TABLE_NAME='PRODUCT_BOM' 4 and COLUMN_NAME not like '%$%' 5 order by COLUMN_ID; TABLE_NAME COLUMN_NAME DATA_TYPE HIDDEN_COLUMN -------------------- --------------- ------------------------------ ------------- PRODUCT_BOM PRODUCT_ID NUMBER NO PRODUCT_BOM PART_ID NUMBER NO PRODUCT_BOM SUPPLIER_ID NUMBER NO PRODUCT_BOM EFFECTIVE_DATE DATE NO PRODUCT_BOM CHANGE_REASON VARCHAR2 NO PRODUCT_BOM APPROVED_BY VARCHAR2 NO 6行が選択されました。
通常のテーブルオブジェクトと同様に列の追加ができました。
次に列を削除します。
A社では内部監査部門の求めに応じるために運用を変更し、承認者は行の挿入時にブロックチェーン表のデジタル署名機能
を用いて署名することとしました。
その結果、APPROVED_BY列が不要となりこの列を削除することになりました。
SQL> alter table PRODUCT_BOM drop (APPROVED_BY); 表が変更されました。
列の削除も通常のテーブルオブジェクトと同様に実施できました。
しかしブロックチェーン表の場合、内部の振る舞いが通常のテーブルオブジェクトとは異なります。
ブロックチェーン表では、暗号化ハッシュを維持するために実際に列を定義から「削除」するのではなく、不可視列として内部に保持します。
SQL> select TABLE_NAME,COLUMN_NAME,DATA_TYPE,HIDDEN_COLUMN 2 from USER_TAB_COLS 3 where TABLE_NAME='PRODUCT_BOM' 4 order by COLUMN_ID; TABLE_NAME COLUMN_NAME DATA_TYPE HIDDEN_COLUMN -------------------- ------------------------------ ------------------------------ ------------- PRODUCT_BOM PRODUCT_ID NUMBER NO PRODUCT_BOM PART_ID NUMBER NO PRODUCT_BOM SUPPLIER_ID NUMBER NO PRODUCT_BOM EFFECTIVE_DATE DATE NO PRODUCT_BOM CHANGE_REASON VARCHAR2 NO ・・・省略・・・ PRODUCT_BOM APPROVED_BY_30_ORABCTAB$ VARCHAR2 YES
とはいえ、ユーザーの目線としては削除された列のデータはSELECT結果に含まれないため、実質的に「列を削除した」状態と変わりない点はご安心いただけるかと思います。
これはV2ブロックチェーン表の機能ではありませんが、26aiのアップデートとして、ブロックチェーン表の保存期間の最大日数を初期化パラメータ「BLOCKCHAIN_TABLE_RETENTION_THRESHOLD」で定めることができます。
Oracle AI Database『Database Reference 26ai』（オラクル社のサイトに移動します）
2.38 BLOCKCHAIN_TABLE_RETENTION_THRESHOLD
これは非常に長い期間、削除が不可なブロックチェーン表が乱立し、表領域をひっ迫してしまうような状況を避けるために、CREATE BLOCKCHAIN TABLEの「NO DROP UNTIL n DAYS IDLE」で指定できる最大の日数を制御するためのパラメータです。
次の例では、BLOCKCHAIN_TABLE_RETENTION_THRESHOLDパラメータが16と設定されているため、「格納された最新の行データの経過日数が17日未満の場合にテーブルをDROPできない」という定義では、ブロックチェーン表を作成できません。
SQL> conn system/AAshisuto--99@Lin96:1521/freepdb1 接続されました。 SQL> show parameter BLOCKCHAIN_TABLE_RETENTION_THRESHOLD NAME TYPE VALUE ------------------------------------ --------------------------------- ------------------------------ blockchain_table_retention_threshold integer 16 SQL> conn knakagaki/pass@Lin96:1521/freepdb1 接続されました。 SQL> create BLOCKCHAIN TABLE PRODUCT_BOM 2 (PRODUCT_ID number not null, 3 PART_ID number not null, 4 SUPPLIER_ID number not null, 5 EFFECTIVE_DATE date not null, 6 constraint FK_PRODUCT 7 foreign key (PRODUCT_ID) references PRODUCTS(PRODUCT_ID), 8 constraint FK_PART 9 foreign key (PART_ID) references PARTS(PART_ID), 10 constraint FK_SUPPLIER 11 foreign key (SUPPLIER_ID) references SUPPLIERS(SUPPLIER_ID)) 12 no drop UNTIL 17 DAYS IDLE 13 no delete UNTIL 16 DAYS AFTER INSERT 14 hashing using "SHA2_512" 15 WITH ROW VERSION AND USER CHAIN RV_PRODUCT_PART (PRODUCT_ID, PART_ID) 16 VERSION "V2"; create BLOCKCHAIN TABLE PRODUCT_BOM * 行1でエラーが発生しました。: ORA-05807: ブロックチェーンまたは不変表"KNAKAGAKI"."PRODUCT_BOM"のアイドル状態の保持は、16日を超えることはできません。 ヘルプ: https://docs.oracle.com/error-help/db/ora-05807/
これにより、長期間DROPできないブロックチェーン表の乱立という事態は抑えることができます。
よりプライオリティの高いデータを扱うテーブルが必要なシーンにおいて、BLOCKCHAIN_TABLE_RETENTION_THRESHOLDに定められた16日を超える大きな日数DROPされない定義のブロックチェーン表を作成したい場合もあるでしょう。
このようなニーズに応えるためだけに、ブロックチェーン表の保存期間の最大日数をシステム全体に対して変更するのは得策とは言えません。
そこで、このBLOCKCHAIN_TABLE_RETENTION_THRESHOLDパラメータのしきい値制限を受けない、より強いシステム権限「TABLE RETENTION
」をご紹介します。
システム権限の付与となるため、SYSユーザーまたはSYSTEMユーザーからTABLE RETENTION権限をブロックチェーン表のオーナーへ与えます。
SQL> conn system/AAshisuto--99@Lin96:1521/freepdb1
接続されました。
SQL> grant TABLE RETENTION to KNAKAGAKI;
権限付与が成功しました。
TABLE RETENTION権限が与えられたユーザーは、BLOCKCHAIN_TABLE_RETENTION_THRESHOLDパラメータのしきい値を超えた日数を指定してブロックチェーン表の作成や、ALTER TABLE文で定義を変更できます。
SQL> conn knakagaki/pass@Lin96:1521/freepdb1 接続されました。 SQL> create BLOCKCHAIN TABLE PRODUCT_BOM 2 (PRODUCT_ID number not null, 3 PART_ID number not null, 4 SUPPLIER_ID number not null, 5 EFFECTIVE_DATE date not null, 6 constraint FK_PRODUCT 7 foreign key (PRODUCT_ID) references PRODUCTS(PRODUCT_ID), 8 constraint FK_PART 9 foreign key (PART_ID) references PARTS(PART_ID), 10 constraint FK_SUPPLIER 11 foreign key (SUPPLIER_ID) references SUPPLIERS(SUPPLIER_ID)) 12 no drop UNTIL 17 DAYS IDLE 13 no delete UNTIL 16 DAYS AFTER INSERT 14 hashing using "SHA2_512" 15 WITH ROW VERSION AND USER CHAIN RV_PRODUCT_PART (PRODUCT_ID, PART_ID) 16 VERSION "V2"; 表が作成されました。 SQL> select TABLE_NAME,TABLE_INACTIVITY_RETENTION,TABLE_VERSION 2 from USER_BLOCKCHAIN_TABLES; TABLE_NAME TABLE_INACTIVITY_RETENTION TABLE_VERSION -------------------- -------------------------- --------------------- PRODUCT_BOM 17 V2 SQL> alter table PRODUCT_BOM no drop UNTIL 18 DAYS IDLE; 表が変更されました。 SQL> select TABLE_NAME,TABLE_INACTIVITY_RETENTION,TABLE_VERSION 2 from USER_BLOCKCHAIN_TABLES; TABLE_NAME TABLE_INACTIVITY_RETENTION TABLE_VERSION -------------------- -------------------------- --------------------- PRODUCT_BOM 18 V2
このTABLE RETENTION権限を持つユーザーは、最大365,000日（1,000年）まで自由に保持期間を設定、変更が可能となります。
TABLE RETENTION権限は非常に強力な権限ですので、システム全体の保持期間のしきい値（BLOCKCHAIN_TABLE_RETENTION_THRESHOLDパラメータ）を適切に見積もることと、必要最小限のユーザーにTABLE RETENTION権限を与えるというバランスを十分に理解し実装することが必要です。
ブロックチェーン表は、SYSDBAですらデータを変更できないという、データの堅牢性と耐改ざん性を提供します。これは、企業のデータガバナンスやセキュリティポリシーの根幹を技術的に担保する強力なソリューションです。
しかし、21cまでのV1ブロックチェーン表では「一度定義した列を変更できない」「データを更新できない」といった仕様上の強い制限があり、変化の速いビジネス要件への対応が難しく、採用のハードルとなっていたと考えられます。
26aiから登場したV2ブロックチェーン表は、この課題を解決します。
従来の堅牢な耐改ざん性を引き継ぎながらも、「行バージョン」や「列の追加と削除」が可能になりました。
これにより、システムは運用開始後も要件変更や業務プロセスの変更などによるテーブルの定義変更にも対応できるようになりました。
V2ブロックチェーン表は、
この2つを両立させ、将来の変化にも耐えうるデータガバナンス基盤の構築に貢献します。
ぜひ26ai以降ならではのセキュリティ対策として、V2ブロックチェーン表の採用もご一考ください。
|
|---|
アシスト北海道
2016年アシスト北海道へ入社後、Oracle Databaseのサポート業務に従事。現在はサポートチームのリーダーとしてメンバーのバックフォローの傍ら、Oracle Databaseの技術検証に勤しんでいる。...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)
