database-management_skill

This skill helps you optimize Autonomous Databases on OCI by troubleshooting connections, managing PDBs, cloning, and cost-aware operations.
  • Shell

4

GitHub Stars

2

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill acedergren/oci-agent-skills --skill database-management

  • metadata.json548 B
  • SKILL.md13.2 KB

Overview

This skill provides practical Oracle Cloud Infrastructure (OCI) database management guidance focused on Autonomous Database (ADB) operations, troubleshooting, and cost optimization. It concentrates on connection string pitfalls, wallet issues, backup and clone patterns, PDB lifecycle mistakes, and common cost traps. Use this to avoid configuration errors, reduce unexpected bills, and apply safe operational choices for ADB and PDBs.

How this skill works

The skill inspects common failure modes and decision points: wallet and TNS configuration, service-name selection (HIGH/MEDIUM/LOW), lifecycle state checks, and network access controls for private vs public endpoints. It also evaluates cost tradeoffs (stop vs scale, clone types, BYOL vs license-included) and backup retention patterns to produce actionable recommendations. For precise OCI CLI/API actions, it instructs relying on exact vendor commands rather than guessing syntax.

When to use it

  • Troubleshooting connection failures: wallet errors, TNS_ADMIN, or incorrect service name.
  • Deciding cost optimizations: stop/start vs scale-down, auto-scaling limits, or BYOL evaluation.
  • Planning backups and retention: manual vs automatic backups and long-term retention.
  • Choosing clone types: full, refreshable, or metadata clones for dev/test/prod needs.
  • Managing PDBs: listing, unplugging, plugging, and avoiding accidental CDB deletion.

Best practices

  • Match ADB service name to workload: HIGH only for critical OLTP; LOW for background jobs to save costs.
  • Never assume stopped = free: storage and backups continue to incur charges.
  • Create least-privilege application users; never embed ADMIN credentials in app code.
  • Before deleting a CDB, list and handle PDBs explicitly (unplug, clone, or delete each).
  • Use refreshable clones for periodic test refreshes and full clones for permanent dev copies.

Example use cases

  • Resolve 'wallet' or 'connection refused' errors by validating TNS_ADMIN, sqlnet.ora, wallet password, and endpoint ACLs.
  • Compare stop/start vs scale-down for a dev ADB used 8 hours/day and calculate monthly savings.
  • Switch from a full clone to a refreshable clone to cut test environment cost by ~70%.
  • Prepare for decommission: perform a manual backup before deleting an ADB to preserve data beyond automatic retention.
  • Fix PDB connection issues by using the PDB service name (sqlplus user/pass@host:1521/PDB1) instead of connecting to the CDB.

FAQ

No. Stopping frees compute but storage and backup retention charges continue, so plan expected savings accordingly.

Which ADB service name should I use for batch jobs?

Use LOW for background or batch workloads to increase concurrency and lower effective cost for non-critical jobs.

When should I use a refreshable clone vs a full clone?

Use refreshable clones for test environments that need periodic updates from production; use full clones when you need a permanent, independent copy.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational