Add Oracle MAA database skill

README.md

@@ -23,7 +23,7 @@ npx skills add oracle/skills/graal
 
 ## Domains
 
-- `db/` is the active Oracle Database domain and includes database, ORDS, SQLcl, framework, container, and agent workflow skills.
+- `db/` is the active Oracle Database domain and includes database, ORDS, SQLcl, framework, Maximum Availability Architecture, container, and agent workflow skills.
 - `oci/` is the root for future Oracle Cloud Infrastructure skills.
 - `fusion/` is the root for future Oracle Fusion skills.
 - `apex/` is the root for future Oracle APEX skills.
@@ -50,6 +50,7 @@ npx skills add oracle/skills/graal
 │   ├── devops/
 │   ├── features/
 │   ├── frameworks/
+│   ├── maa/
 │   ├── migrations/
 │   ├── monitoring/
 │   ├── ords/

db/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: db
-description: Oracle Database guidance for SQL, PL/SQL, SQLcl, ORDS, administration, app development, performance, security, migrations, and agent-safe database workflows. Use when the user asks to write, edit, rewrite, review, format, debug, tune, or explain SQL; create or refactor PL/SQL; use SQLcl, Liquibase, ORDS, JDBC, node-oracledb, Python, Java, .NET, or database frameworks; troubleshoot queries, sessions, locks, waits, indexes, optimizer plans, AWR, ASH, migrations, schemas, users, roles, privileges, backup, recovery, Data Guard, RAC, multitenant, containers, monitoring, auditing, encryption, VPD, or safe agent database operations.
+description: Oracle Database guidance for SQL, PL/SQL, SQLcl, ORDS, administration, app development, performance, security, migrations, Maximum Availability Architecture (MAA), and agent-safe database workflows. Use when the user asks to write, edit, rewrite, review, format, debug, tune, or explain SQL; create or refactor PL/SQL; use SQLcl, Liquibase, ORDS, JDBC, node-oracledb, Python, Java, .NET, or database frameworks; troubleshoot queries, sessions, locks, waits, indexes, optimizer plans, AWR, ASH, migrations, schemas, users, roles, privileges, backup, recovery, Data Guard, RAC, Exadata, MAA tiers, Oracle Update Advisor, multicloud MAA, multitenant, containers, monitoring, auditing, encryption, VPD, or safe agent database operations.
 ---
 
 # Oracle Database Skills
 
-This domain contains Oracle Database skills for administration, SQL and PL/SQL development, performance tuning, security, ORDS, SQLcl, migrations, frameworks, OCR container guidance, and agent-safe database workflows.
+This domain contains Oracle Database skills for administration, SQL and PL/SQL development, performance tuning, security, ORDS, SQLcl, migrations, Maximum Availability Architecture, frameworks, OCR container guidance, and agent-safe database workflows.
 
 ## How to Use This Domain
 
@@ -26,6 +26,7 @@ db/
 ├── devops/
 ├── features/
 ├── frameworks/
+├── maa/
 ├── migrations/
 ├── monitoring/
 ├── ords/
@@ -50,6 +51,7 @@ db/
 | Schema migrations, online operations, edition-based redefinition, testing, version control | `db/devops/` |
 | AQ, DBMS_SCHEDULER, materialized views, DBLinks, APEX, vector search, SELECT AI | `db/features/` |
 | SQLAlchemy, Django, Pandas, Spring JPA, MyBatis, TypeORM, Sequelize, Dapper, GORM | `db/frameworks/` |
+| Maximum Availability Architecture, MAA tiers, Data Guard/RAC/Exadata MAA, Oracle Update Advisor, Edition-Based Redefinition, ZDLRA, multicloud MAA, mission-critical availability | `db/maa/` |
 | Migrations from PostgreSQL, MySQL, SQL Server, MongoDB, Snowflake, and more | `db/migrations/` |
 | Alert log, ADR, health monitor, space management, top SQL | `db/monitoring/` |
 | ORDS architecture, installation, REST design, authentication, monitoring, ORDS Concert Sample App | `db/ords/` |
@@ -69,6 +71,11 @@ db/
 - `db/devops/schema-migrations.md`
 - `db/agent/schema-discovery.md`
 - `db/containers/container-selection-matrix.md`
+- `db/maa/maa-overview.md`
+- `db/maa/maa-tiers.md`
+- `db/maa/data-guard-maa.md`
+- `db/maa/patching-update-advisor.md`
+- `db/maa/source-index.md`
 - `db/backup-recovery/autonomous-recovery-service.md`
 - `db/backup-recovery/cloud-protect.md`
 
@@ -82,3 +89,4 @@ db/
 | Build a Java JDBC service | `java-oracle-jdbc` → `java-oracle-jdbc/dependencies` → `java-oracle-jdbc/connections` → `java-oracle-jdbc/sql` → `java-oracle-jdbc/pooling-production` |
 | Perform agent-safe schema change | `schema-discovery` → `destructive-op-guards` → `idempotency-patterns` → `schema-migrations` |
 | Set up AI-driven database access via MCP | `sqlcl-basics` (save connections) → `security/privilege-management` (least-privilege user) → `sqlcl-mcp-server` (configure + start) |
+| Answer an MAA architecture or availability question | `maa-overview` → focused MAA topic file → `source-index` when citations are needed |

db/maa/application-continuity.md

@@ -0,0 +1,48 @@
+# Application Continuity And Client Failover
+
+Use this file when users ask how to reduce or hide application interruption during database outages, planned maintenance, service relocation, RAC node failure, Data Guard switchover/failover, or connection pool disruptions.
+
+## Core Guidance
+
+- Availability is not complete until clients reconnect to the right service quickly and safely.
+- Use database services as the unit of availability and workload placement. Do not connect applications to individual instances unless there is a deliberate reason.
+- Use HA-aware connection strings with multiple addresses, appropriate connect timeouts, retry behavior, and service names.
+- Use Fast Application Notification (FAN) so clients and pools react quickly to service up/down and load events.
+- Use Transaction Guard to determine transaction outcome after recoverable errors.
+- Use Application Continuity or Transparent Application Continuity where supported to replay safe requests and mask outages from users.
+- Use connection draining and service relocation for planned maintenance instead of abruptly breaking sessions.
+
+## RAC And Data Guard Application Pattern
+
+| Layer | MAA expectation |
+|---|---|
+| Database services | Define services by workload and role; use role-based services for Data Guard when appropriate. |
+| Connection string | Include all relevant SCAN/listener endpoints and tune timeouts so failures are detected quickly. |
+| Driver/pool | Use Oracle drivers/pools that understand FAN, Runtime Load Balancing, and Application Continuity features. |
+| Application | Make requests replay-safe where possible; handle non-replayable calls explicitly. |
+| Operations | Test service relocation, node failure, switchover, failover, and planned maintenance paths. |
+
+## What Can And Cannot Be Hidden
+
+- Connection failures can often be shortened with HA connection strings, FAN, and pool integration.
+- Planned maintenance interruption can often be minimized with service draining and rolling operations.
+- Some in-flight work can be replayed when Application Continuity requirements are met.
+- Non-idempotent external side effects, unprotected session state, and unsafe calls may still require application logic.
+- Data Guard role transitions require service and client behavior to be designed and tested; the database switchover alone is not the full user experience.
+
+## Common Mistakes
+
+- Using a single host in the connect descriptor.
+- Setting long TCP/connect timeouts that make failover appear hung.
+- Forgetting role-based services after Data Guard switchover.
+- Assuming AC/TAC can replay every request without checking driver, service, and application requirements.
+- Testing only database role transition and not the application pool behavior.
+
+## Sources
+
+- RAC Administration and Deployment Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/index.html
+- RAC technical architecture: https://docs.oracle.com/en/database/oracle/oracle-database/26/adrac/index.html
+- Continuous Availability: https://www.oracle.com/a/ocom/docs/database/continuous-availabiliity.pdf
+- Fast Application Notification: https://www.oracle.com/a/ocom/docs/database/fast-application-notification.pdf
+- Application checklist for continuous availability: https://www.oracle.com/a/tech/docs/application-checklist-for-continuous-availability-for-maa.pdf
+- High availability connection string: https://blogs.oracle.com/maa/the-high-availability-connection-string-explained

db/maa/backup-recovery-zdlra.md

@@ -0,0 +1,48 @@
+# Backup, Recovery, RMAN, And ZDLRA
+
+Use this file for MAA backup/recovery strategy, RMAN, restore validation, corruption protection, recovery objectives, and Zero Data Loss Recovery Appliance positioning.
+
+## Core Guidance
+
+- Backups remain mandatory even with RAC, Data Guard, or Active Data Guard.
+- Design recovery around both RTO and recovery point requirements, including logical corruption and user error.
+- Validate restore and recovery, not just backup job success.
+- Keep backup retention, immutability, encryption, offsite copies, and compliance requirements explicit.
+- Use standby databases to offload backups where it fits the architecture and licensing.
+- Use ZDLRA when the requirement is centralized, database-aware protection, incremental-forever strategy, recovery validation, and stronger recovery automation for Oracle databases.
+
+## Data Guard Versus Backup
+
+| Capability | Data Guard | Backup/RMAN/ZDLRA |
+|---|---|---|
+| Fast database failover | Yes | No |
+| Protection from site failure | Yes, with remote standby | Yes, depending on copy location and restore time |
+| Point-in-time recovery | Limited by standby/flashback strategy | Core capability |
+| Logical error recovery | Not sufficient by itself | Core capability |
+| Long retention | Not the primary purpose | Core capability |
+| Corruption detection/repair workflow | Helps in database-aware ways | Required for full recovery strategy |
+
+## Recovery Readiness Checklist
+
+- Define the recovery scenarios: media failure, site loss, operator error, corruption, ransomware, failed patch, failed deployment.
+- Confirm where backups live and whether they survive the failure domain.
+- Test restore to alternate location.
+- Test point-in-time recovery.
+- Track backup encryption keys and wallet/secret availability.
+- Monitor backup age, recoverability, failed jobs, restore performance, and recovery catalog health where used.
+
+## Common Mistakes
+
+- Reporting “backup succeeded” without proving restore works.
+- Keeping backups in the same failure domain as the database.
+- Assuming Data Guard protects against all logical mistakes.
+- Ignoring recovery time for very large databases.
+- Not testing wallet/key availability during restore.
+
+## Sources
+
+- Backup and Recovery IAD: https://docs.oracle.com/en/database/oracle/oracle-database/26/bkupr/index.html
+- Backup and Recovery User's Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/bradv/index.html
+- Backup and Recovery Reference: https://docs.oracle.com/en/database/oracle/oracle-database/26/rcmrf/index.html
+- ZDLRA Protected Database Configuration Guide: https://docs.oracle.com/en/engineered-systems/zero-data-loss-recovery-appliance/23.1/ampdb/index.html
+- ZDLRA Administrator's Guide: https://docs.oracle.com/en/engineered-systems/zero-data-loss-recovery-appliance/23.1/amagd/index.html

db/maa/data-guard-maa.md

@@ -0,0 +1,57 @@
+# Data Guard MAA Guidance
+
+Use this file for the MAA layer of Data Guard and Active Data Guard decisions. For low-level Data Guard syntax and administration mechanics, lean on existing Oracle Database Data Guard skills or current product documentation.
+
+## MAA Positioning
+
+- Data Guard is the primary Oracle database-aware DR technology for physical standby, role transition, and redo-based recovery across sites or clouds.
+- Active Data Guard adds read-only workload offload, reporting, backups from standby, and additional use cases while redo apply continues.
+- Data Guard Broker should be the default management path for MAA-style operations because it centralizes configuration, validation, switchover, failover, and Fast-Start Failover.
+- Use Data Guard for planned maintenance as well as disaster recovery: standby-first patching, switchover, validation, and fallback planning reduce outage risk.
+
+## Key Architecture Decisions
+
+| Decision | Guidance |
+|---|---|
+| Protection mode | Match RPO and latency. Maximum Performance favors distance and commit latency; Maximum Availability targets zero/near-zero data loss where SYNC latency is acceptable; Maximum Protection is specialized and can stop the primary if protection is unavailable. |
+| Transport | Choose SYNC/ASYNC based on RPO, distance, latency, redo rate, and application commit sensitivity. Validate with workload, not only network theory. |
+| Standby type | Physical standby is the default for broad compatibility and DR. Snapshot standby is for temporary testing. Logical approaches or GoldenGate solve different requirements. |
+| Broker | Prefer Broker for operational consistency, validation, and role transitions. |
+| FSFO | Use when automatic failover is required and the organization accepts the operational model. Deploy observers carefully and test failure conditions. |
+| Client failover | Data Guard alone does not make applications transparent. Pair role transitions with services, connection strings, FAN, AC/TAC, and pool behavior. |
+
+## Operational Best Practices
+
+- Configure standby redo logs appropriately and validate real-time apply when low RPO matters.
+- Enable and test Flashback Database where reinstatement after failover is part of the operational plan.
+- Run regular switchovers, not just tabletop exercises.
+- Monitor transport lag, apply lag, archive gaps, observer health, database role, protection level, and service placement.
+- Size and test redo transport for peak redo generation, not only average redo rate.
+- Document decision criteria for switchover, failover, reinstate, and fallback. During an incident, ambiguity burns RTO.
+- For hybrid or multicloud deployments, validate network latency, routing, security controls, DNS behavior, and operational ownership across providers.
+
+## Standby-First Maintenance Pattern
+
+1. Validate the Data Guard configuration and application failover readiness.
+2. Patch or upgrade the standby side first where supported.
+3. Allow redo/apply to catch up and validate health.
+4. Switchover to make the patched standby primary.
+5. Patch the former primary.
+6. Optionally switch back after validation, or keep the new role if that is the operational standard.
+
+## Common Mistakes
+
+- Failing over manually without checking for redo gaps and data loss implications.
+- Having Data Guard configured but not application services and connection strings.
+- Letting the standby lag silently grow until RTO/RPO assumptions are false.
+- Using storage replication as if it provided the same database-aware protection as Data Guard.
+- Not testing reinstate after failover.
+
+## Sources
+
+- Data Guard Concepts and Administration: https://docs.oracle.com/en/database/oracle/oracle-database/26/sbydb/index.html
+- Data Guard Broker: https://docs.oracle.com/en/database/oracle/oracle-database/26/dgbkr/index.html
+- Data Guard patch maintenance: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbpdg/index.html
+- Active Data Guard scaling context: https://blogs.oracle.com/maa/application-and-ai-scalability-with-oracle-active-data-guard
+- Redo transport throughput context: https://blogs.oracle.com/maa/higher-data-guard-redo-transport-throughput
+- ADG vs. storage mirroring: https://www.oracle.com/docs/tech/adg-vs-storage-mirroring-v1.pdf

db/maa/edition-based-redefinition.md

@@ -0,0 +1,42 @@
+# Edition-Based Redefinition
+
+Use this file for zero or near-zero downtime application upgrades that involve database object changes. EBR is an application/database deployment technique, not a DR substitute.
+
+## When EBR Fits
+
+- The application requires database schema changes while existing users continue running.
+- Changes involve editionable objects such as PL/SQL, views, synonyms, and related application-facing database APIs.
+- The team can route old and new application code to different editions during rollout.
+- The deployment can be broken into phases: prepare, expose compatibility layer, run old and new code, cut over, and clean up.
+
+## Core Concepts
+
+- An edition provides a private namespace for editioned objects.
+- Editioning views decouple application-facing table shape from physical table changes.
+- Crossedition triggers can keep old and new representations synchronized during online rollout.
+- Sessions run in an edition; application services or connection configuration can control which edition new sessions use.
+- Cleanup is a separate step after confidence is established.
+
+## MAA Guidance
+
+- Use EBR for application upgrade downtime, not infrastructure failure.
+- Combine EBR with RAC services and connection draining for controlled rollout.
+- Combine EBR with Data Guard only after considering redo/apply impact and operational sequencing.
+- Test rollback/fallback explicitly. EBR can make fallback easier, but only if the deployment plan preserves compatibility.
+- Keep external side effects, batch jobs, and non-editioned objects in the plan.
+
+## Common Mistakes
+
+- Treating EBR as a switch that makes any schema change online without design.
+- Forgetting that tables are not editioned in the same way as PL/SQL and views.
+- Skipping editioning views and exposing physical table changes directly to the application.
+- Not planning cleanup of old editions and compatibility objects.
+- Rolling out application servers without controlling which edition their sessions use.
+
+## Sources
+
+- EBR overview: https://www.oracle.com/database/technologies/high-availability/ebr.html
+- EBR documentation: https://docs.oracle.com/en/database/oracle/oracle-database/26/adfns/editions.html
+- EBR technical deep dive: https://www.oracle.com/a/tech/docs/ebr-technical-deep-dive-overview.pdf
+- EBR FAQ: https://www.oracle.com/a/tech/docs/ebr-faq.pdf
+- EBR MAA blog: https://blogs.oracle.com/maa/edition-based-redefinition-a-solution-for-zero-downtime-application-upgrades