mcpField
O
oracle-dba

oracle-dba

github.com/acedergren数据与数据库22134 次安装33 周前更新
代码仓库

关于 oracle-dba

oracle-dba 是面向 OCI Oracle Autonomous Database 管理员和开发者的参考技能,涵盖 ADB 运维、故障排查、性能调优与成本考量,并指引使用相关 CLI 工作流。

主要功能

  1. 01ADB 运维的 OCI CLI 指引
  2. 02SQL_ID 查询故障排查
  3. 03性能调优决策流程
  4. 04ADB 成本与扩缩容指导
  5. 05运维陷阱与最佳实践

适用场景

  1. 01诊断 ADB 慢查询
  2. 02规划计算扩容与成本
  3. 03管理 ADB 备份和克隆
  4. 04规避生产 SQL 常见风险

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/acedergren/oci-agent-skills --skill oracle-dba

安装后在 Claude Code 中输入/oracle-dba确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

metadata.json
references/
oci-adb-best-practices.md
oci-cli-adb.md
sqlcl-workflows.md

详细介绍

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. 加载 oci-cli-adb.md 以执行 ADB 管理操作

你确实了解的内容:

  • 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 个 ECPU 扩至 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)

❌ 绝不要将 ROWNUM 与 ORDER BY 一起使用(结果错误)

-- 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 调优任务

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:实施修复

  • 建议:添加索引 → 创建索引
  • 建议:使用 hint → 使用 hint 测试,然后创建 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 版本)

功能19c21c23ai26ai使用场景
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 privilegesADMIN 用户尝试执行受限操作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

请勿加载,用于:

  • 常规故障排除建议——本技能的决策树已涵盖
  • 成本计算——上文已提供精确公式
  • 反模式——NEVER 列表涵盖了常见错误

使用 OCI CLI 管理 ADB

何时加载 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 部署
  • 需要 Oracle 官方提供的 ADB 功能和限制指南
  • 规划从本地 Oracle 迁移到 ADB

请勿加载,用于:

  • 快速调试 SQL_ID(本技能中包含工作流)
  • 成本计算(上文已提供精确公式)
  • 常见问题(NEVER 列表已涵盖)

何时使用此技能

  • 性能问题:查询缓慢、CPU 使用率高、扩展决策
  • 成本优化:ECPU 规格选择、已停止的 ADB 费用、备份保留
  • 调试:SQL_ID 工作流、等待事件、执行计划
  • 自动扩展:何时启用、成本影响、限制
  • 版本规划:功能比较(19c 与 26ai)、升级时机
  • 安全性:ADMIN 限制、用户设置、服务名选择

评论

支持 Markdown