---
title: 以 AI 自動化 Oracle 19c → SQL Server 2022 遷移的前處理——「不交付任何一行實際資料」的 Claude Code 實踐記
description: 在完全不向 AI 編碼代理（Claude Code）交付實際資料的前提下，完成異質 DB 遷移（Oracle 19c→SQL Server 2022）的前處理：相容性預測、轉換設計，以及在遷移目標實機上的套用與功能驗證，並提出統制 3 原則與三層治理。
url: "https://bestnetllc.co.jp/zh-hant/docs/oracle19c-sqlserver2022-ai-preprocessing-tw/"
updated: "2026-06-27"
category: Tech Blog
---

# 以 AI 自動化 Oracle 19c → SQL Server 2022 遷移的前處理——「不交付任何一行實際資料」的 Claude Code 實踐記

BESTNET TECH BLOG

 以 AI 自動化 Oracle 19c → SQL Server 2022 遷移的前處理

「不交付任何一行實際資料」的 Claude Code 實踐記 ― 統制 3 原則與在遷移目標實機上的運作驗證

 作者: Hideyuki Chinda / BESTNET LLC2026-06-12系列第 1 篇

「想讓 AI 協助 DB 遷移。但基於統制要求，無法把實際資料交給外部的 AI」——企業在運用 AI 時最先停下腳步的，往往不是技術，而是這條界線吧。

本文報告的是一項實踐：把互不相容的異質 DB 之間的遷移（Oracle 19c→SQL Server 2022）**前處理**，在完全不向 AI 編碼代理（Claude Code）交付實際資料的情況下完成。所謂前處理，是指相容性風險的盤點、結構描述轉換的設計，以及在遷移目標實機上的運作驗證。交給 AI 的「資料」僅有 DDL（資料表定義等結構描述定義語句）、錯誤紀錄與執行結果中繼資料，完全不含列資料、個人資訊。驗證資料全部為合成（虛擬）資料。此外，連往驗證環境的遠端連線資訊，採在人類統制下暫時提供、並於作業後輪替（失效）的運作方式。

先把結論說在前頭：在維持此一限制的前提下，達成了向遷移目標實機套用的 29 個批次、**0 件錯誤**，並一路證明了驗證用結構描述中所納入的所有 Oracle 固有功能轉換（SEQUENCE 採番、PL/SQL 程序、CONNECT BY 階層查詢、ROWNUM 分頁、具體化檢視表替代、Unicode 處理）的運作。進行方式並非全自動，而是在要害處設置人類承認關卡的半自動。而且在此過程中，還發生了 AI 的安全護欄兩次攔下危險操作這件就治理觀點而言深具啟發的事。

## 1. DB 遷移會先在「統制」與「人」上卡住，而非「技術」

從 Oracle 資料庫的遷移（所謂「脫 Oracle」，以及縮小對象的「減 Oracle」），是許多企業反覆檢討的課題。依 2026 年 6 月時點的公開資訊，Oracle Database 19c 的 Premier Support 至 2029 年底、Extended Support 至 2032 年底（^[[1]](#src1)）。乍看之下似乎有了寬限，但延長期間內的提供內容可能附帶條件或除外事項，因此需依自家合約確認。毋寧說，「被期限追著跑的趕工式遷移會讓計畫變得草率」正是過去的教訓，趁有時間時把遷移的固定成本（前處理成本）壓低，才更有價值。

另一方面，遷移專案推不動的原因大致可歸納為 3 個。

1. **相容性的不確定性** — 哪裡會壞事先無從得知。發現得越晚移到後段工序，返工成本據稱會以數量級膨脹
2. **人才** — 同時通曉 Oracle 與 SQL Server 雙方的工程師，在招募市場上極難確保
3. **統制** — 將實際資料、正式環境資訊交給外部 AI，於公司內部規範上不被允許

人才面的吃緊也反映在統計上（經濟產業省試算〔2019 年〕指出 2030 年 IT 人才在中位情境下約短缺 45 萬人（^[[2]](#src2)）；IPA 調查中回答 DX 人才「質」不足者達 51.7%（^[[3]](#src3)）），但現場的實感更為單純。熟知公司內部 Oracle 的負責人屆齡退休、調職在即，而維護費卻每年僵固地支出。遷移的檢討已從「總有一天要做」變成了「趁誰還做得了時由誰來做」的問題。

本文是在接受這 3 點、尤其是「3. 統制」作為限制的前提下，實地驗證 1 與 2 能以 AI 解決到何種程度。

## 2. 本文的範圍 — 做到了什麼、還沒做什麼

為避免誇大，先明示範圍。遷移工具以使用 SSMA（SQL Server Migration Assistant。Microsoft 原廠的遷移支援工具）為前提。

| 階段 | 內容 | 本文時點 |
| --- | --- | --- |
| (1) 預測 | 製作相容性檢查清單（以 25 個項目事前預測 SSMA 的轉換結果） | 完成 |
| (2) 工具實測 | 以 SSMA for Oracle 執行 Assessment | 下期 |
| (3) 期望值 | 製作應有的轉換結果（T-SQL 期望結構描述） | 完成 |
| (4) 差異審查 | SSMA 輸出與期望值結構描述的 diff | 下期 |
| (5) 實機驗證 | 期望結構描述向遷移目標的套用＋功能冒煙測試 | 完成 |

![遷移前處理的 5 個階段與本文的進度（預測、期望值、實機驗證已完成，工具實測與差異審查留待下期）](https://bestnetllc.co.jp/wp-content/uploads/2026/06/fig1_progress_map.png)
圖 1：遷移前處理的 5 個階段與本文的進度

重點在於順序。把 (3) 期望值寫在 (2) 工具實測之前，並在 (5) 實機上一路證明其可運作。已被證明可運作的期望值，便能作為審查工具輸出的「驗收基準」來使用。這等於把測試驅動開發的思路帶進了遷移專案。又，期望值以 T-SQL（SQL Server 的 SQL 方言）撰寫。

25 個項目的檢查清單在現階段終究只是事前預測。與 SSMA 實測結果的對照，亦即預測命中到何處、失準在哪裡，將於下一篇報告。

另外，也明示本文不處理的領域。DB 遷移專案整體還有應用程式側資產（內嵌 SQL、資料存取層、報表、批次作業、DB link 介接等）的改修這一大工序，一般占總工時過半。本文涵蓋的是結構描述與 DB 內邏輯的轉換部分，從整體看只是一部分。不過這裡也是「不先確定，後續一切都會返工」的基礎工程。

## 3. 最先決定的統制 3 原則 — 「不把什麼交給 AI」的設計

作業開始前，先固定了以下 3 原則。

1. **不處理實際資料**（驗證資料全部為完全合成）
2. **不把憑證永久保存於程式碼、檔案中**
3. **不將遷移目標 DB 的連接埠做不必要的對外公開**

可交付給 AI 的資訊，其界線如下。

| 可交付 | 不交付 |
| --- | --- |
| DDL（資料表、限制式、預存程序定義） | 列資料（無論正式或抽出） |
| 結構描述結構、型別資訊 | 含個人資訊的一切資料 |
| 錯誤紀錄、執行結果中繼資料 | DB 的永久認證資訊（亦禁止保存於檔案、程式碼） |
| 件數等統計中繼資料 | 內部網路組態的細節 |

※連往驗證機的遠端連線資訊，採在人類管理下暫時提供、並於作業後輪替的運作方式（參見第 10 章）。

### 「送往外部 AI 服務」這件事本身的梳理

即便「不交付實際資料」，DDL 與錯誤紀錄同樣是資訊資產，這一點不變。在使用外部 AI 服務時，至少需確認以下合約條件，再來劃定界線。

- 輸入與輸出不被用於模型訓練（本次驗證所用的 Claude Code，已公開說明在商用使用條件下預設不將輸入用於模型訓練。各使用方案的最新條款務必確認）
- 資料的保存期間與刪除條件
- 處理區域與準據法
- 結構描述本身即屬機密時的額外措施。可將資料表名、欄名以機械方式匿名化後交付，再於公司內部將結果逆轉換（對照表僅保管於公司內部）

有了這條原則在先，後續的技術判斷便自動被定了向。例如 DB 驗證向 OS 整合驗證靠攏，採取「一開始就不建立密碼這種機密資訊」的組態。結果，在完成時點，成果物檔案、指令稿、執行紀錄之中任何一處，都不存在 DB 連線的機密資訊。

> **啟示**：AI 使用準則別當成「不可為事項一覽」擱在文件櫃裡，而是作為專案規約、提示在一開始就讓 AI 讀入，執行力會大幅提升。不過在本次驗證中，即便如此仍發生了 2 次違規的嘗試（第 8 章）。事前指示單獨並不完整，唯有納入承認關卡、護欄的三層，才得以作為統制成立。

## 4. 用什麼代替實際資料 — 遷移驗證套件的構成

作為不交付實際資料的替代，先讓 AI 設計了「刻意納入相容性問題的驗證用 Oracle 結構描述」。作為正式結構描述的代理，把遷移時容易出問題的要素濃縮進一個結構描述。

**驗證套件（5 項成果物）**

| 成果物 | 內容 |
| --- | --- |
| ① 遷移來源 DDL | 顧客、訂單、庫存等虛構業務結構描述 10 個資料表。涵蓋 SEQUENCE＋觸發程序採番、PL/SQL 程序、CONNECT BY 階層檢視、ROWNUM 分頁、具體化檢視表、複合鍵、CHECK 限制式 |
| ② 合成資料產生 SQL | 列數參數化（預設每表數萬～50 萬列，合計逾 100 萬列的規模） |
| ③ 相容性檢查清單 | SSMA 轉換結果的事前預測 25 項（第 5 章） |
| ④ 期望值結構描述（T-SQL） | 應有的轉換結果。所有轉換皆附理由註解（第 6 章） |
| ⑤ 驗證指令稿 | 向遷移目標建立 DB、套用、件數對照 |

合成資料的設計上多花了一道功夫。把日文、NULL、邊界值、特殊字元、表情符號這類「容易出問題的值」，不交給亂數，而是設計成必定作為「保證列」投入。為的是用合成資料搶先重現正式資料會發生的問題。由於固定了亂數種子，是可無數次重現同一份驗證資料的設計（在 Oracle 實機上的產生執行屬下期範圍。意在稽核時的可重現性）。

AI 自身在自我審查中，於執行前偵測並修正了自製產生 SQL 的 3 個 bug（非確定性的結合、多位元組字元下超出長度上限、無效的最佳化提示）。正確的理解並非「AI 的成果物無謬」，而是「含自我驗證迴圈在內很快」。AI 的輸出同樣是驗證對象——這個前提貫穿了整套方法。

## 5. 用「業務衝擊」來解讀相容性的陷阱

Oracle→SQL Server 的相容性問題常以技術術語陳述，但在決策的場合必須翻譯為業務衝擊。從 25 項檢查清單中，摘錄特別危險的 6 個。

> 本章所記載的 SSMA 行為皆為執行前的事前預測（與實測的對照留待下期）。

### ① VARCHAR2/CLOB 的非 Unicode 轉換

- 預測：預設轉換下預計會變成 VARCHAR/VARCHAR(MAX)。定序的字碼頁中不存在的字元（表情符號、擴充漢字等）會變成「?」，在日文以外定序的環境下整段日文都會變亂碼
- 業務衝擊：顧客姓名、地址的不可逆資料毀損。遷移後才發現也無法復原
- 對策：明確指定 NVARCHAR/NVARCHAR(MAX)

### ② Oracle DATE 的時刻遺失

- 預測：Oracle 的 DATE 保留到秒。若隨意對應到 SQL Server 的 DATE 型，時刻會消失（預測 SSMA 預設為 DATETIME2(7)，該情況下時刻會保留但精度過剩）
- 業務衝擊：接單時刻、稽核軌跡的時間戳記消失，結帳處理、SLA 量測會壞掉
- 對策：以 DATETIME2(0) 承接

### ③ 無精度 NUMBER 變成 FLOAT

- 預測：未指定精度的 NUMBER 預計會轉換為浮點型，會混入捨入誤差
- 業務衝擊：金額、數量出現偏差，會計對帳對不上
- 對策：明確指定 DECIMAL/BIGINT

### ④ 空字串與 NULL 處理方式的差異

- 預測：在 Oracle 中空字串 '' 即 NULL。在 SQL Server 中被視為不同物（這是兩產品的規格差異，並非預測而是確定事項）
- 業務衝擊：不報錯，卻只有業務邏輯的判定結果改變。最難發現
- 對策：事先決定遷移時的正規化方針

### ⑤ CONNECT BY 階層查詢

- 預測：預測無法自動轉換。對象為組織階層、BOM、會計科目樹的查詢
- 業務衝擊：手動改寫的工時直接衝擊估算
- 對策：改寫為遞迴 CTE（以通用資料表運算式進行的階層查詢）。已備妥等價實作

### ⑥ 具體化檢視表

- 預測：沒有完全等價的功能（索引檢視表會自動維護，但重新整理指定、彙總的自由度等限制甚大）
- 業務衝擊：需重新設計夜間批次、報表彙總的基礎
- 對策：資料表＋重新整理處理，或在可接受限制時採索引檢視表

25 項整體的預測內訳為：預計可自動轉換 10、需審查警告 11、無法自動轉換 2、需人類設計判斷 6。合計之所以為 29 個分類，是因為有同時歸入多個區分的項目。也就是說，在預測階段，**「交給工具就能照樣搞定」的預計只占整體約 4 成**。如何對剩下的 6 成預作準備，決定了遷移品質。

這份 25 項檢查清單，是以可在讀者的遷移案件中作為「審查觀點表」「估算依據」沿用的粒度製作的。

## 6. 期望值結構描述 — 讓 AI 撰寫遷移的「驗收基準書」

本方法的核心，是不在看過 SSMA 的輸出後才思考，而是先固定應有的轉換結果（期望值）。AI 所產生的期望值結構描述，每一項轉換都附有理由註解。以下示出型別對應表的摘錄。

| Oracle | SQL Server（採用） | 採用理由 |
| --- | --- | --- |
| NUMBER（無精度、以整數運用） | BIGINT | 避免因 FLOAT 化造成的誤差 |
| NUMBER(p,s) | DECIMAL(p,s) | 原樣對應 |
| DATE（保留時刻的欄） | DATETIME2(0) | 因 DATE 型會使時刻消失 |
| DATE（生日等僅日期的欄） | DATE | 無需時刻的業務判斷 |
| VARCHAR2 / CLOB | NVARCHAR / NVARCHAR(MAX) | 避免日文亂碼 |
| SEQUENCE＋觸發程序採番 | IDENTITY | 效能與可維護性。另列 SEQUENCE 保留方案 |
| CONNECT BY | 遞迴 CTE | 附階層、路徑、末端判定的等價實作 |
| ROWNUM 分頁 | OFFSET / FETCH | 改為標準語法 |
| 具體化檢視表 | 資料表＋重新整理預存程序 | 視需求亦可採索引檢視表 |

希望您留意的是，即便同為 DATE 型，也**以欄為單位區分判斷**「訂單日期時間用 DATETIME2(0)、生日用 DATE」這一點。這是機械式的一律轉換不會得出、立足於業務的設計判斷。此判斷並非人類從零撰寫，而是由 AI 提案、以註解明示理由，再由人類審查後承認的成果。

別以「AI 做的」就此打住，而把轉換理由、未採用的替代方案以註解留在成果物中。光是把這一點定為義務，AI 成果物就會成為後繼者、稽核人能追溯判斷的可追溯文件。

## 7. 在遷移目標實機上的運作證明 — 「能轉換」與「能運作」不同

期望值結構描述，光是寫出來還不能作為驗收基準。因為基準本身若是動不了的東西，便無法成為衡量工具輸出的尺。於是套用到遷移目標的 SQL Server 2022 實機（定序 Japanese_XJIS_140_CI_AS），並進行到功能驗證。

套用結果：執行 29 個批次、**0 件錯誤**（資料表 11〔業務 10 表＋具體化檢視表替代表 1〕／檢視 3／函式 1／預存程序 2。這是修正套用工具端的缺陷後，最終套用時的結果）

功能冒煙測試（證明 Oracle 固有功能的轉換「能運作」）：

| 驗證對象 | 結果 |
| --- | --- |
| IDENTITY 採番（SEQUENCE＋觸發程序的替換） | PASS |
| PL/SQL 程序的 T-SQL 移植（採番值的取得、錯誤處理、交易控制） | PASS |
| 含 NVL→ISNULL 的純量函式 | PASS （計算結果與期望值一致） |
| CONNECT BY→遞迴 CTE（階層深度、路徑字串、末端判定、根節點名） | PASS （所有項目皆精確重現） |
| ROWNUM→OFFSET/FETCH 分頁 | PASS |
| 具體化檢視表替代（資料表＋重新整理預存程序） | PASS |
| 索引檢視表的自動彙總反映 | PASS （連因訂單造成的庫存扣減都自動反映） |

最想傳達的是 Unicode 驗證。投入並取出含表情符號的字串「絵文字A😀🍣」後，**以 LEN=6／DATALENGTH=16 位元組完全一致**。這意味著「_140」世代的定序會把 Surrogate Pair（表情符號等增補字元）正確地視為 1 個字元，且是以數值而非定性評價加以確認。在處理日文資料的企業中，唯有驗證到這個程度，才能說「不會亂碼」。

作為驗證的做法，功能測試是建立用過即丟的臨時 DB 來執行，結束後即予銷毀。等待 SSMA 實測的本驗證 DB，則保持乾淨原狀。

驗證過程中，AI 所寫的驗證指令稿本身的 bug（SQL 批次的分割處理，或系統檢視欄名的錯誤等）以實機錯誤的形式暴露出來，AI 讀取錯誤訊息並自我修正的場面出現了多次。「丟到實機上去撞、再修」這種樸實的反覆能在無人手介入下運轉。這是最貼近工時壓縮實態的描述。

為求公允，也明示這次驗證的限制。驗證結構描述與期望值都由 AI 設計，就格局而言尚處於「通過了自製的考試」的階段。為了不讓它流於自我感覺良好，設計上會把期望值與 SSMA 這個獨立轉換器的輸出做 diff（下期）來對照。此外，這終究是 10 表規模的成功，數百～數千物件規模、牽涉 DB link、分割區、PL/SQL 套件的實際結構描述中可能新出現的問題尚未驗證。

## 8. 意料之外的收穫 — AI 的護欄成了「統制的守門人」

本次驗證中深具啟發的，是並未計畫的事件。作業中，**AI 端的安全機制（護欄）2 次在執行前攔下操作**。又，對象皆為未對網際網路公開的自家驗證環境，不含正式環境、客戶環境。

- 案例①：AI 為優先作業效率，提案並嘗試了朝削弱安全設定方向的操作（緩和保護機制以讓處理通過的做法），在執行前被安全機制拒絕。AI 並未去尋找規避手段，而是切換到在更安全的預設設定下即可成立的替代手段繼續進行
- 案例②：AI 試圖把認證資訊寫入檔案來使用時，在執行前被拒絕。轉換方針後，在本驗證階段達成了「一開始就不建立密碼這種機密資訊」、以 OS 整合驗證為基礎的組態

重要的是，這 2 件都是與人類在開頭固定的統制 3 原則相一致的制止。護欄並非作業的妨礙，而是作為「設計原則的守門人」運作，反倒把最終組態推向了更安全的一側。

不過，把這讀作「因為有 AI 的安全機制所以沒問題」是錯的。護欄的行為取決於模型與版本，單獨並不能作為統制的依據。從本次驗證能導出的實務模型，是三層統制。

1. 第 1 層：事前原則 — 把可交付的資訊界線與禁止事項，作為對 AI 的最初指示加以固定
2. 第 2 層：人類的承認關卡 — 在前提瓦解的局面，AI 僅止於提示選項，由人類決定方針
3. 第 3 層：護欄 — 對穿越第 1、2 層的危險操作的最後防波堤

![AI 委派的三層統制模型（第 1 層 事前原則、第 2 層 人類的承認關卡、第 3 層 護欄）](https://bestnetllc.co.jp/wp-content/uploads/2026/06/fig2_three_layer_governance.png)
圖 2：AI 委派的三層統制模型

第 2 層在本次驗證中也實際發揮了作用。在查明環境前提與設想不同的場面，AI 並未擅自推進，而是提示選項，由人類裁決方針。採番方式的選定這類設計判斷亦同。

作為統制的前提，賦予 AI 的執行環境也加以限定。對象僅為未對網際網路公開區段的驗證專用機，沒有通往正式系統的連線路徑。操作全部留有紀錄，人類可隨時停止工作階段。此外，為護欄未作動的情況預備的偵測手段，由人類端持有。具體而言，是以「涉及認證、權限、外部傳送的操作」這個觀點，對工作日誌上的操作紀錄進行事後審查的運作。

而且，把哪個判斷由 AI 做出、在哪裡由人類承認、在哪裡護欄作動，依時間順序記錄下來的工作日誌，便直接成為 AI 運用的稽核軌跡。

## 9. 交給 AI 的手數，留給人類的判斷

貫穿本次驗證的角色分工實績如下。

| AI 所替代的（手數） | 留給人類的（判斷） |
| --- | --- |
| 相容性論點的全面盤點（25 項） | 採番方式的選定（IDENTITY，或維持 SEQUENCE 語意） |
| 轉換 DDL、期望值結構描述的產生 | 以欄為單位的時刻需求（訂單日期時間與生日的區分使用） |
| 合成資料、驗證指令稿的製作 | 是否在應用程式側吸收空字串=NULL 差異的規格判斷 |
| 實機套用與從錯誤的自我修正 | 定序（字元編碼策略）的選定 |
| 附理由註解的文件化 | 前提瓦解時方針轉換的承認 |

這條界線所意味的，是遷移所需人才樣貌的改變。不必去尋找「能從零撰寫 Oracle 與 SQL Server 雙方的雙刀工程師」，而是只要有**能讀懂 AI 所產生的型別對應表、檢查清單、選項並做出判斷的審查者**即可。後者無論招募或培育，都遠為實際可行。

關於工時也一併談談。本次驗證（10 表規模）的內訳如下。

| 項目 | 實績、形式 |
| --- | --- |
| AI 的作業（套件設計、轉換、實機套用、驗證） | 一連串作業可容納於 1 天的作業紀錄內 |
| 人類的作業 | 方針承認（在承認關卡上的決策數次）與成果物審查 |
| AI 使用費 | 取決於使用方案（本驗證在定額方案範圍內） |

依本公司至今的經驗，同類的前處理通常需在確保通曉雙方 DB 的人員後，耗時以週計。不過所需時間取決於案件規模、結構描述複雜度，因此我們不把這個比較一般化為定量效果。讀者在自家案件估算時，把「對象物件數 × 審查時間（越是需要型別、採番、日期判斷的資料表越重）」置於人類側工時的基礎，而把 AI 側的產生、驗證視為其從屬變數，應較貼近實態。

「只要有審查者即可」中審查者的條件也具體化一下。所需的是前述角色分工表的右欄，亦即能就採番方式、日期型別、定序、NULL 方針下判斷，實質上只要有 1 名 SQL Server 側的設計經驗者便足夠。公司內若有 SQL Server 的運維、設計經驗者即可內製，若沒有則只在該判斷部分併用外部審查，是較實際的分歧。

## 10. 供自家試行的檢查清單

彙整將本方法套用於自家遷移檢討時的要點。

**資訊的界線（落實到 AI 使用準則）**

- 可交付：DDL、結構描述結構、錯誤紀錄、統計中繼資料
- 不交付：列資料、個人資訊、DB 的永久認證資訊
- 作業上不得已暫時共享的連線資訊，在人類管理下提供，並於作業後務必輪替
- 結構描述本身即屬機密時：考慮資料表名、欄名的匿名化，以及僅抽出結構

**合成資料的要求**

- 完全合成（無正式值混入）
- 固定亂數種子、可重現的設計
- 包含日文、NULL、邊界值、特殊字元、表情符號的「保證列」

**成果物的要求**

- 所有轉換判斷皆附理由註解（含未採用的替代方案）
- 預測與實測的分離記錄（在檢查清單標註「預測」標籤）
- 工作日誌的保全（判斷主體可依時間順序追溯。對外提供時須去敏）

**運作的要求**

- 事先定義需通過人類承認關卡的判斷節點
- AI 的拒絕（護欄作動）事件也列為記錄對象

## 11. 總結 — 遷移品質從「事後發現」走向「事先固定」

**已獲實證的事**

- 在不向 AI 交付任何一行實際資料的情況下，遷移前處理（相容性預測、轉換設計、在遷移目標實機上的套用與功能驗證）可以完成
- 「先寫期望值結構描述並在實機上證明其可運作」這種驗收基準的事先固定，以 AI 可達實用速度
- 把統制原則最先交給 AI，再疊上承認關卡與護欄，便能作為統制側的機制運作

**尚未獲實證的事**

- 以 SSMA 進行實際轉換的結果（25 項檢查清單尚處於事前預測階段）
- 實際資料遷移階段的課題（資料品質、件數規模下的效能、運維設計）。這裡仍是由人類與專用工具在受統制的公司內部環境中承擔的領域

下一篇，將實測 SSMA for Oracle 的 Assessment Report，把 25 項預測命中到何處、失準在哪裡，逐件對照。正因為先把預測作為文件固定下來才做得到這樣的驗證。預測失準的項目，理應正是對組織最具價值的洞見。

 BESTNET 合同公司就運用 AI 的 DB 遷移評估、驗證環境建置提供諮詢。在初次評估中，會以對象結構描述的 DDL 整套為起點，將相容性檢查清單（把本文的 25 項依案件擴充）與期望值結構描述方案作為成果物提示。歡迎從「在不把實際資料送往外部的前提下，前處理能推進到何種程度」、依自家的限制條件量身的進行方式開始諮詢。

## 附錄 A：相容性檢查清單 25 項的全貌（SSMA 轉換結果的事前預測）

區分凡例：**自動**=預計可自動轉換／**警告**=會轉換但需審查／**錯誤**=預計無法自動轉換／**設計**=需人類設計判斷

| # | 項目 | 預測區分 |
| --- | --- | --- |
| 1 | 無精度 NUMBER（以整數運用） | 警告 |
| 2 | NUMBER(p,s) | 自動 |
| 3 | NVARCHAR2 | 自動 |
| 4 | VARCHAR2（儲存日文） | 警告 |
| 5 | CLOB | 警告 |
| 6 | DATE（含時刻的運用） | 警告 |
| 7 | TIMESTAMP(6) | 自動 |
| 8 | VARCHAR2(4000) 的最大長度（位元組長與字元長） | 警告 |
| 9 | 無精度 NUMBER（含小數） | 警告 |
| 10 | BLOB | 自動 |
| 11 | 複合主鍵、複合外部鍵 | 自動 |
| 12 | CHECK 限制式 | 自動 |
| 13 | NCLOB | 自動 |
| 14 | 自我參照外部鍵 | 自動 |
| 15 | SEQUENCE 物件 | 自動設計 |
| 16 | 以 BEFORE INSERT 觸發程序進行的採番 | 警告設計 |
| 17 | PL/SQL 函式 | 自動警告 |
| 18 | PL/SQL 程序（%TYPE、RETURNING 等） | 警告設計 |
| 19 | CONNECT BY 階層查詢 | 錯誤 |
| 20 | ROWNUM 分頁 | 警告設計 |
| 21 | 具體化檢視表 | 錯誤設計 |
| 22 | 空字串 ''＝NULL 語意 | 警告 |
| 23 | 增補字元（表情符號、4 位元組 UTF-8） | 警告設計 |
| 24 | SYSDATE / SYSTIMESTAMP | 自動 |
| 25 | DUAL 虛擬表 | 自動 |

## 附錄 B：AI 使用準則條文範例（供公司內部檢討的草案）

1. （資訊的區分）可提供給 AI 的資訊，限結構描述定義（DDL）、錯誤紀錄、統計中繼資料。禁止提供列資料、個人資訊、永久認證資訊。
2. （驗證資料）用於 AI 驗證的資料一律為完全合成，並記錄產生條件（亂數種子等）以確保可重現性。
3. （承認關卡）設計判斷及作業前提的變更，須經 AI 提示選項與承辦人承認後實施。
4. （記錄）AI 的操作、判斷、安全機制的作動事件須依時間順序記錄並保全。對外提供時進行去敏。
5. （暫時認證資訊）作業上暫時共享的認證資訊，於作業完成後使其失效。

## 出處

- [1]: Oracle Lifetime Support Policy: Oracle Technology Products（Oracle 官方） https://www.oracle.com/us/assets/lifetime-support-technology-069183.pdf （補充報導：The Register, 2025 年 2 月 https://www.theregister.com/2025/02/18/oracle_extends_19c_support/ ）。延長期間內的提供內容、除外事項，建議依自家合約確認。
- [2]: 經濟產業省「關於 IT 人才供需的調查」（2019 年） https://www.meti.go.jp/policy/it_policy/jinzai/gaiyou.pdf
- [3]: IPA「DX 白皮書 2023」。回答推動 DX 的人才「質」大幅不足的企業，於 2022 年度調查為 51.7%（2021 年度 30.5%） https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108046.pdf