oracle-dba

OCI Oracle DBA - エキスパート向けナレッジ

🏗️ OCI Landing Zone Terraform モジュールを使用する

車輪の再発明はしないでください。 データベースインフラストラクチャには、oracle-terraform-modules/landing-zone を使用してください。

Landing Zone で解決できる問題：

• ❌ 悪いプラクティス #1：汎用コンパートメント（Landing Zone は ADB の組織に専用の Database／Security コンパートメントを作成します）
• ❌ 悪いプラクティス #9：パブリックなデータベースエンドポイント（Landing Zone Security Zones により、プライベートエンドポイントのみが適用されます）
• ❌ 悪いプラクティス #10：監視なし（Landing Zone は ADB のパフォーマンスアラームと低速クエリ通知を自動設定します）

このスキルが提供するもの：Landing Zone 内にデプロイされたデータベース向けの、ADB 固有の操作、パフォーマンスチューニング、コスト最適化です。

---

⚠️ OCI CLI／API に関する知識の不足

OCI CLI コマンドや OCI API の構造については把握していません。

トレーニングデータには、以下に関する知識が限られており、古くなっています。

• OCI CLI の構文とパラメーター（月次で更新）
• OCI API エンドポイントとリクエスト／レスポンス形式
• Autonomous Database の CLI 操作（oci db autonomous-database）
• OCI サービス固有のコマンドとフラグ
• 最新の OCI 機能と API の変更

OCI の操作が必要な場合：

1. このスキルのリファレンスにある正確な CLI コマンドを使用してください
2. OCI CLI の構文やパラメーターを推測しないでください
3. API エンドポイントの構造を決めつけないでください
4. ADB 管理操作については oci-cli-adb.md を読み込んでください

把握している内容：

• Oracle Database の内部知識（SQL、PL/SQL、パフォーマンスチューニング）
• クラウド全般の概念
• データベース管理の原則

このスキルは、Autonomous Database の操作に必要な最新の OCI CLI／API コマンドを提供することで、この不足を補います。

---

あなたは OCI 上の Oracle Autonomous Database のエキスパートです。このスキルは、Claude が持たない知識、つまり ADB 固有の動作、コスト上の落とし穴、SQL_ID のデバッグ手順、自動スケーリングの注意点、本番環境で避けるべきアンチパターンを提供します。

絶対にしてはいけないこと

❌ アプリケーションコードで ADMIN ユーザーを絶対に使用しないでください

-- WRONG - application uses ADMIN credentials
app_config = {'user': 'ADMIN', 'password': admin_pwd}

-- RIGHT - create app-specific user with least privilege
CREATE USER app_user IDENTIFIED BY :password;
GRANT CREATE SESSION, SELECT ON schema.* TO app_user;

重要な理由：ADMIN はデータベースを完全に制御でき、監査証跡にはすべての操作が ADMIN によるものとして記録されます（説明責任がありません）。また、自動化を損なわずに ADMIN をロックまたは無効化することはできません。

❌ 待機イベントを先に確認せず、絶対にスケールしないでください

-- WRONG decision path: "CPU is high → scale ECPUs"

-- RIGHT decision path:
1. Check v$system_event for top wait events
2. High 'CPU time' wait → Bad SQL, need optimization (DON'T scale)
3. High 'db file sequential read' → Missing indexes (DON'T scale)
4. High 'User I/O' sustained → Scale storage IOPS OR auto-scaling
5. Only scale ECPUs if: CPU wait sustained + SQL already optimized

コストへの影響：2 から 4 ECPU へのスケーリングで、月額 526 ドルの増加になります。根本原因が不適切な SQL であれば、月額 526 ドルが無駄になります。

❌ 停止した ADB はコストがゼロだと決めつけないでください

Stopped Autonomous Database charges:
✓ Compute: $0 (stopped)
✗ Storage: $0.025/GB/month continues
✗ Backups: Retention charges continue

Example: 1TB ADB stopped for 30 days
Storage: 1000 GB × $0.025 = $25/month (CHARGED!)

Better for long-term idle (>60 days):
1. Export data (Data Pump)
2. Delete ADB
3. Restore from backup when needed

❌ 手動バックアップの保持期間を絶対に忘れないでください（コスト上の落とし穴）

# WRONG - manual backup with no retention (kept forever)
oci db autonomous-database-backup create \
  --autonomous-database-id $ADB_ID \
  --display-name "pre-upgrade-backup"
# Cost: $0.025/GB/month FOREVER

# RIGHT - set retention
oci db autonomous-database-backup create \
  --autonomous-database-id $ADB_ID \
  --display-name "pre-upgrade-backup" \
  --retention-days 30

Cost trap: 1TB manual backup × $0.025/GB/month × 12 months = $300/year waste

❌ 本番環境のクエリで SELECT * を絶対に使用しないでください

-- WRONG - fetches all columns, heavy network/parsing
SELECT * FROM orders WHERE customer_id = :cust_id;

-- RIGHT - specify needed columns
SELECT order_id, total_amount, status FROM orders WHERE customer_id = :cust_id;

Impact: 50-column table, fetching 5 needed columns
- SELECT *: 50 columns × 1000 rows = 50k data points
- Explicit: 5 columns × 1000 rows = 5k data points (90% reduction)

❌ 低速クエリをデバッグする際に SQL_ID を絶対に無視しないでください

-- WRONG - "my query is slow, tune the database"
ALTER SYSTEM SET optimizer_mode = 'FIRST_ROWS';  # Affects ALL queries!

-- RIGHT - identify specific SQL_ID, tune that query
SELECT sql_id, elapsed_time/executions/1000 AS avg_ms, executions
FROM v$sql
WHERE executions > 0
ORDER BY elapsed_time DESC
FETCH FIRST 10 ROWS ONLY;

Then tune specific SQL_ID (not entire database)

❌ ORDER BY と ROWNUM を絶対に併用しないでください（誤った結果になります）

-- WRONG - ROWNUM applied BEFORE ORDER BY (wrong top 10)
SELECT * FROM orders WHERE ROWNUM <= 10 ORDER BY created_at DESC;

-- RIGHT - FETCH FIRST (Oracle 12c+)
SELECT * FROM orders ORDER BY created_at DESC FETCH FIRST 10 ROWS ONLY;

❌ 現在の動作を確認せず、自動スケーリングを有効にした ADB を絶対にスケールしないでください

ADB Auto-Scaling Gotcha:
- Base ECPU: 2
- Auto-scaling: Scales 1-3x (2 → 6 ECPU max)
- Cost: Charged for PEAK usage during period

# WRONG - enable auto-scaling then forget about it
Cost surprise: Base 2 ECPU ($526/month) → Peak 6 ECPU ($1,578/month)

# RIGHT - set max ECPU limit in console
Max ECPU = 4 (2× base, not 3×)
Cost control: Peak 4 ECPU ($1,052/month) max

パフォーマンスのトラブルシューティング決定木

"Queries are slow"?
│
├─ Is it ONE query or ALL queries?
│  ├─ ONE query slow
│  │  └─ Get SQL_ID from v$sql (top by elapsed_time)
│  │     └─ Check execution plan:
│  │        SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('&sql_id'));
│  │        ├─ Full table scan? → Add index
│  │        ├─ Wrong join order? → Use hints or SQL Plan Management
│  │        └─ Cartesian join? → Fix query logic
│  │
│  └─ ALL queries slow (system-wide)
│     └─ Check wait events:
│        SELECT event, time_waited_micro/1000000 AS wait_sec
│        FROM v$system_event
│        WHERE wait_class != 'Idle'
│        ORDER BY time_waited_micro DESC
│        FETCH FIRST 10 ROWS ONLY;
│
│        ├─ Top wait: 'CPU time' → Optimize SQL OR scale ECPU
│        ├─ Top wait: 'db file sequential read' → Missing indexes
│        ├─ Top wait: 'db file scattered read' → Full table scans
│        ├─ Top wait: 'log file sync' → Too many commits (batch)
│        └─ Top wait: 'User I/O' → Scale storage IOPS or auto-scale
│
└─ When did slowness start?
   ├─ After schema change? → Gather stats (DBMS_STATS)
   ├─ After data load? → Gather stats + check partitioning
   ├─ After version upgrade? → Check execution plan changes
   └─ Gradual over time? → Data growth, need indexing/partitioning

ADB のコスト計算（正確な値）

ECPU のスケーリングコスト

License-Included pricing: $0.36/ECPU-hour
BYOL pricing: $0.18/ECPU-hour (if you have Oracle licenses)

Monthly cost = ECPU count × hourly rate × 730 hours

Examples:
2 ECPU: 2 × $0.36 × 730 = $526/month
4 ECPU: 4 × $0.36 × 730 = $1,052/month
8 ECPU: 8 × $0.36 × 730 = $2,104/month

BYOL (50% off):
2 ECPU: 2 × $0.18 × 730 = $263/month
4 ECPU: 4 × $0.18 × 730 = $526/month

ストレージコスト

Storage pricing: $0.025/GB/month (all tiers: Standard, Archive)

Examples:
1 TB: 1000 GB × $0.025 = $25/month
5 TB: 5000 GB × $0.025 = $125/month

CRITICAL: Storage charged even when ADB stopped!

自動スケーリングのコストへの影響

Scenario: Base 2 ECPU with auto-scaling enabled (1-3×)

Without auto-scaling:
2 ECPU × $0.36 × 730 = $526/month (fixed)

With auto-scaling (spiky load):
- 50% of time: 2 ECPU = $263
- 30% of time: 4 ECPU = $315
- 20% of time: 6 ECPU = $315
Monthly cost: $893 (70% increase)

When auto-scaling makes sense:
- Spiky load (not sustained high)
- Want to avoid manual scaling
- Cost increase acceptable (up to 3×)

SQL_ID のデバッグ手順

ステップ 1：問題のある SQL_ID を見つける

SELECT sql_id,
       elapsed_time/executions/1000 AS avg_ms,
       executions,
       sql_text
FROM v$sql
WHERE executions > 0
  AND last_active_time > SYSDATE - 1/24  -- Last hour
ORDER BY elapsed_time DESC
FETCH FIRST 10 ROWS ONLY;

ステップ 2：実行計画を取得する

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('&sql_id'));

ステップ 3：実行計画の問題を分析する

• 大規模なテーブルで TABLE ACCESS FULL → インデックスが不足しています
• カーディナリティの高い NESTED LOOPS → 結合方法が適切ではありません
• HASH JOIN OUTER → インデックス結合を検討してください

ステップ 4：SQL Tuning Task を作成する

DECLARE
  task_name VARCHAR2(30);
BEGIN
  task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(
    sql_id => '&sql_id',
    task_name => 'tune_slow_query'
  );
  DBMS_SQLTUNE.EXECUTE_TUNING_TASK(task_name);
END;
/

-- Get recommendations
SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK('tune_slow_query') FROM DUAL;

ステップ 5：修正を適用する

• 推奨事項：インデックスの追加 → インデックスを作成する
• 推奨事項：ヒントの使用 → ヒントを使ってテストし、その後 SQL Plan Baseline を作成する
• 推奨事項：統計情報の収集 → EXEC DBMS_STATS.GATHER_TABLE_STATS

ADB 固有の動作（OCI の注意点）

自動スケーリングの制限

Auto-scaling rules (cannot change):
- Minimum: 1× base ECPU
- Maximum: 3× base ECPU
- Scaling trigger: CPU > 80% for 5+ minutes
- Scale-down: CPU < 60% for 10+ minutes
- Time to scale: 5-10 minutes

Example: Base 2 ECPU
- Can scale: 2 → 4 → 6 ECPU
- Cannot scale: Beyond 6 ECPU (hard limit)
- Cost: Pay for peak usage each hour

ADMIN ユーザーの制限

In Autonomous Database, ADMIN user:
✓ Can: Create users, grant roles, DDL operations
✗ Cannot: Create tablespaces (DATA is auto-managed)
✗ Cannot: Modify SYSTEM/SYSAUX tablespaces
✗ Cannot: Access OS (no shell, no file system)
✗ Cannot: Use SYSDBA privileges (not available in ADB)

For applications:
- ADMIN: Only for database setup/maintenance
- App users: Create dedicated users with minimal grants

サービス名がパフォーマンスに与える影響

ADB provides 3 service names per database:

| Service | CPU Allocation | Concurrency | Use For |
|---------|---------------|-------------|---------|
| HIGH | Dedicated OCPU | 1× ECPU | Interactive queries, OLTP |
| MEDIUM | Shared OCPU | 2× ECPU | Reporting, batch jobs |
| LOW | Most sharing | 3× ECPU | Background tasks, ETL |

Cost: All service names use same ECPU pool (no extra cost)
Performance: HIGH is faster but limits concurrency
Gotcha: Using HIGH for background jobs wastes resources

バックアップの保持期間（自動と手動）

Automatic backups (free, included):
- Frequency: Daily incremental, weekly full
- Retention: 60 days default (configurable 1-60)
- Cost: Included in ADB storage cost
- Deletion: Automatic after retention period

Manual backups (charged separately):
- Frequency: On-demand
- Retention: FOREVER (until you delete)
- Cost: $0.025/GB/month
- Deletion: Manual only

Cost trap: 10 manual backups × 1TB × $0.025/GB/month = $250/month
Recommendation: Use automatic backups, manual only for long-term archival

バージョン固有の機能（ADB のバージョンを確認）

機能	19c	21c	23ai	26ai	使用する場面
JSON リレーショナル・デュアリティ	-	-	✓	✓	最新のアプリ（REST + SQL）
AI ベクトル検索	-	-	✓	✓	RAG、セマンティック検索
JavaScript ストアドプロシージャ	-	-	-	✓	Node.js 開発者
SELECT AI	-	-	✓	✓	自然言語 → SQL
プロパティグラフ	-	✓	✓	✓	不正検知、ソーシャル
True Cache	-	-	-	✓	読み取り負荷の高いワークロード
ブロックチェーンテーブル	-	✓	✓	✓	改ざん不可能な監査ログ

アップグレードパス：19c → 21c → 23ai → 26ai ダウングレード：サポートされていません（以前のバージョンには戻せません） 推奨事項：本番環境をアップグレードする前に、クローン環境でテストしてください

よくある ADB エラーの解説

エラーメッセージ	実際の原因	解決策
ORA-01017: invalid username/password	ウォレットのパスワードが間違っている、または認証情報の有効期限が切れている	ウォレットを再ダウンロードし、パスワードを確認します
ORA-12170: Connect timeout	ネットワークの問題、またはサービス名が間違っている	NSG ルールを確認し、tnsnames.ora を検証します
ORA-00604: error at recursive SQL level 1	自動タスクに失敗した（統計情報の収集、領域管理）	DBA_SCHEDULER_JOB_RUN_DETAILS を確認します
ORA-30036: unable to extend segment	表領域がいっぱいになっている（DATA は自動管理）	ADB は自動的に拡張します。エラーが続く場合はサポートにお問い合わせください
ORA-01031: insufficient privileges	ADMIN ユーザーが制限された操作を試みている	ADMIN は許可された操作にのみ使用します（制限事項を参照）

高度な操作（段階的な読み込み）

SQLcl によるデータベースへの直接アクセス

次の場合に読み込みます sqlcl-workflows.md：

• Bash 経由で SQL クエリを直接実行する必要がある
• 実行計画、待機イベント、またはアクティブなセッションを取得したい
• SQL チューニングタスク（DBMS_SQLTUNE）を実施する
• Data Pump でデータをエクスポート／インポートする
• スキーマオブジェクトの DDL を生成する

例：経過時間が最も長い SQL を検索する

sql admin/password@adb_high <<EOF
SELECT sql_id, elapsed_time/executions/1000 AS avg_ms
FROM v\$sql WHERE executions > 0
ORDER BY elapsed_time DESC FETCH FIRST 10 ROWS ONLY;
EXIT;
EOF

次の場合は読み込まないでください：

• 標準的なトラブルシューティングのアドバイス。このスキルの判断ツリーで説明しています
• コスト計算。上記に正確な計算式があります
• アンチパターン。よくある間違いは「絶対に避ける」リストで網羅しています

---

ADB 管理用 OCI CLI

次の場合に読み込みます oci-cli-adb.md：

• ADB インスタンスをプロビジョニング、スケーリング、または削除する必要がある
• バックアップまたはクローンを作成する（フルまたはメタデータのみ）
• ウォレットファイルをダウンロードする
• 構成を変更する（自動スケーリング、ライセンスタイプ、バージョンアップグレード）
• 複数の ADB に対して一括操作を行う

例：ADB を 2 ECPU から 4 ECPU にスケーリングする

oci db autonomous-database update \
  --autonomous-database-id ocid1.autonomousdatabase.oc1..xxx \
  --cpu-core-count 4 \
  --wait-for-state AVAILABLE

例：メタデータクローンを作成する（70% 安価。スキーマのみでデータなし）

oci db autonomous-database create-from-clone \
  --source-id ocid1.autonomousdatabase.oc1..xxx \
  --display-name "dev-schema" \
  --db-name "DEVSCHEMA" \
  --clone-type METADATA \
  --wait-for-state AVAILABLE

次の場合は読み込まないでください：

• SQL 操作（代わりに SQLcl を使用します）
• パフォーマンス分析（v$sql クエリはこのスキルで説明しています）
• コスト計算（上記に正確な計算式があります）

---

OCI Autonomous Database のベストプラクティス（Oracle 公式ドキュメント）

次の場合に読み込みます oci-adb-best-practices.md：

• ADB のアーキテクチャと設計パターンを包括的に理解する必要がある
• ADB のワークロードタイプ（ATP、ADW、APEX、JSON）を理解する
• 本番環境向けの ADB デプロイメントを実装する
• ADB の機能と制限について、Oracle 公式のガイダンスが必要である
• オンプレミスの Oracle から ADB への移行を計画する

次の場合は読み込まないでください：

• SQL_ID の迅速なデバッグ（ワークフローはこのスキルで説明しています）
• コスト計算（上記に正確な計算式があります）
• よくある注意点（「絶対に避ける」リストで網羅しています）

---

このスキルを使用する場面

• パフォーマンスの問題：クエリの遅延、CPU 使用率の高さ、スケーリングの判断
• コストの最適化：ECPU のサイジング、停止中の ADB の課金、バックアップの保持期間
• デバッグ：SQL_ID のワークフロー、待機イベント、実行計画
• 自動スケーリング：有効にするタイミング、コストへの影響、制限
• バージョン計画：機能の比較（19c と 26ai）、アップグレードのタイミング
• セキュリティ：ADMIN の制限、ユーザーの設定、サービス名の選択