- Home
- Skills
- Acedergren
- Oci Agent Skills
- Database Management
database-management_skill
- 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.