initial version

kb/sizing/adb-scaling-behavior.yaml

@@ -0,0 +1,57 @@
+---
+last_verified: 2026-03-14
+description: ADB-S auto-scaling behavior, timing, and sizing implications.
+---
+
+auto_scaling:
+  ocpu_scaling:
+    trigger: "CPU demand exceeds current allocation"
+    max_scale: "3x base OCPUs (up to 128 OCPU maximum)"
+    ramp_up_time: "2-3 minutes to begin scaling"
+    ramp_down_time: "After sustained low utilization (5-10 minutes)"
+    billing: "Only billed during active scaling period, per OCPU per second"
+
+  storage_scaling:
+    trigger: "Storage usage approaches allocated storage"
+    behavior: "Auto-expands storage allocation"
+    billing: "Billed for allocated storage"
+
+sizing_recommendations:
+  base_ocpu_strategy: |
+    Size base OCPUs for P75 utilization, not average.
+    Auto-scaling handles P95+ bursts, but the 2-3 minute ramp-up
+    means very short spikes may complete before scaling activates.
+
+  guidelines:
+    - scenario: "Steady OLTP workload"
+      base: "P75 utilization"
+      auto_scale: "Enable, set max to P95 or 2x base"
+    - scenario: "Highly variable workload (2x+ peak/baseline)"
+      base: "P50 utilization"
+      auto_scale: "Enable, set max to 3x base"
+    - scenario: "Batch processing with known peak times"
+      base: "Baseline requirement"
+      auto_scale: "Enable, supplement with scheduled scaling if available"
+    - scenario: "Dev/test"
+      base: "1-2 OCPUs"
+      auto_scale: "Disable to control costs"
+
+connection_impact:
+  connections_per_ocpu: 300
+  example: |
+    Base 8 OCPUs → 2,400 connections
+    Auto-scale to 16 OCPUs → 4,800 connections
+    Connection limits scale with OCPUs automatically
+
+performance_during_scaling:
+  notes:
+    - "Active sessions are not interrupted during scale-up"
+    - "New connections get additional capacity immediately"
+    - "Scale-down uses connection draining — active sessions complete normally"
+    - "Brief performance dip possible during scaling transition"
+
+gotchas:
+  - "Short bursts (<3 min) may complete before auto-scaling activates"
+  - "Very rapid burst from 0 to max can cause connection queuing"
+  - "Auto-scaling cost can surprise if workload is consistently above base"
+  - "Monitor auto-scaling events to right-size base OCPUs over time"

kb/sizing/cpu-conversion-ratios.yaml

@@ -0,0 +1,72 @@
+# CPU Conversion Ratios: vCPU → OCPU
+# Used for right-sizing when migrating from other platforms
+
+conversion_ratios:
+  description: |
+    OCI uses OCPUs (Oracle Compute Units). 1 OCPU = 1 physical core = 2 vCPUs.
+    When migrating from AWS/Azure/GCP, convert vCPUs to OCPUs using these ratios.
+
+  # Source → OCI OCPU conversion
+  aws:
+    general:
+      ratio: "2 AWS vCPUs = 1 OCI OCPU"
+      notes: "AWS vCPU = 1 hyperthread. OCI OCPU = 1 physical core (2 threads)."
+    by_processor:
+      intel_xeon_2nd_gen:  # m5, c5, r5
+        vcpu_to_ocpu: 2.0
+      intel_xeon_3rd_gen:  # m6i, c6i, r6i
+        vcpu_to_ocpu: 2.0
+      amd_epyc_2nd_gen:   # m5a, c5a, r5a
+        vcpu_to_ocpu: 2.0
+        notes: "OCI E4 (AMD EPYC 3rd gen) is typically faster per core"
+      graviton2:           # m6g, c6g, r6g
+        vcpu_to_ocpu: 1.0
+        notes: "Graviton2 vCPU = 1 physical core. Map 1:1 to Ampere A1."
+      graviton3:           # m7g, c7g, r7g
+        vcpu_to_ocpu: 1.0
+        notes: "Map to Ampere A2 for comparable performance."
+
+  azure:
+    general:
+      ratio: "2 Azure vCores = 1 OCI OCPU (for Intel/AMD)"
+    by_processor:
+      intel_dv5:
+        vcpu_to_ocpu: 2.0
+      amd_dv5a:
+        vcpu_to_ocpu: 2.0
+
+  on_prem:
+    oracle_database:
+      description: "Use AWR Top Activity to determine actual core utilization"
+      approach: |
+        1. Get AWR "DB Time per second" for P75 interval
+        2. Divide by number of available cores
+        3. Result = core utilization ratio
+        4. Multiply by source cores to get required OCPUs
+        5. Apply 1.2x headroom factor
+      fallback: "If no AWR data: 1 on-prem core = 1 OCPU (conservative)"
+    vmware:
+      ratio: "2 VMware vCPUs = 1 OCI OCPU"
+      notes: "VMware vCPU is a hyperthread equivalent"
+
+adb_s_sizing:
+  description: |
+    For ADB-S, size base OCPUs for P75 sustained load:
+    - Auto-scaling can go up to 3x base OCPUs
+    - Auto-scaling activation takes 2-3 minutes
+    - If P95 spikes are short (< 2 min), they may hit before scale-out
+    - Size base for P75 to ensure good baseline performance
+
+  formula: |
+    base_ocpus = ceil(p75_cpu_usage / cores_per_ocpu * headroom_factor)
+    headroom_factor = 1.2 (default)
+    auto_scale_max = base_ocpus * 3
+
+memory_sizing:
+  oci_shapes:
+    standard_e4: "16 GB per OCPU (VM.Standard.E4.Flex)"
+    standard_e5: "16 GB per OCPU (VM.Standard.E5.Flex)"
+    standard_a1: "6 GB per OCPU (VM.Standard.A1.Flex / Ampere)"
+    standard_a2: "8 GB per OCPU (VM.Standard.A2.Flex / Ampere)"
+    optimized3: "14 GB per OCPU (VM.Optimized3.Flex)"
+    dense_io_e4: "32 GB per OCPU + local NVMe (VM.DenseIO.E4.Flex)"

kb/sizing/memory-sizing-rules.yaml

@@ -0,0 +1,57 @@
+---
+last_verified: 2026-03-14
+description: Memory sizing guidelines for OCI compute and database workloads.
+---
+
+compute_memory:
+  flexible_shapes:
+    min_gb_per_ocpu: 1
+    max_gb_per_ocpu: 64
+    default_gb_per_ocpu: 16
+    recommendation: |
+      Start with 16 GB per OCPU for general workloads.
+      Java applications: 8-16 GB per OCPU.
+      In-memory caches (Redis, Memcached): size for data set + 20%.
+      Database client/app servers: 8 GB per OCPU usually sufficient.
+
+  common_ratios:
+    general_purpose: 16  # GB per OCPU
+    memory_intensive: 32
+    compute_intensive: 8
+    java_application: 12
+    web_server: 8
+
+database_memory:
+  adb_s:
+    notes: "Memory managed automatically by ADB. Not directly configurable."
+    sga_estimate: "~7 GB per OCPU"
+    pga_estimate: "~2.5 GB per OCPU"
+
+  exacs:
+    notes: "Memory allocated per VM cluster from Exadata infrastructure pool"
+    recommendation: "Size VM cluster memory based on SGA+PGA requirements"
+    typical_sga_per_ocpu: 8
+    typical_pga_per_ocpu: 3
+
+  dbcs:
+    notes: "Memory = compute shape memory. Choose shape accordingly."
+    recommendation: |
+      Total DB memory = SGA + PGA aggregate
+      SGA = 60-80% of available memory
+      PGA = 10-20% of available memory
+      OS overhead = 10-15%
+
+sizing_from_source:
+  on_prem_oracle_to_oci:
+    steps:
+      - "Get current SGA + PGA sizes from AWR/ASH"
+      - "Add 15% for OS overhead"
+      - "Map to compute shape with sufficient memory"
+      - "For ADB: translate to OCPU count (memory scales automatically)"
+    notes: "ADB auto-tunes memory, so OCPU sizing is the key input"
+
+  aws_rds_to_oci:
+    steps:
+      - "Note current instance class memory"
+      - "Map to equivalent OCI shape memory"
+      - "For ADB: divide memory by 10 to estimate OCPU count"

kb/sizing/storage-iops.yaml

@@ -0,0 +1,74 @@
+# OCI Storage IOPS and Throughput Reference
+# Used for right-sizing block and file storage
+
+block_volume:
+  description: "OCI Block Volume performance tiers"
+  tiers:
+    - name: "Lower Cost"
+      iops_per_gb: 2
+      max_iops: 3000
+      throughput_mbps_per_gb: 0.024
+      max_throughput_mbps: 480
+      use_when: "Archive, cold data, infrequent access"
+
+    - name: "Balanced"
+      iops_per_gb: 60
+      max_iops: 25000
+      throughput_mbps_per_gb: 0.48
+      max_throughput_mbps: 480
+      use_when: "General purpose, boot volumes, typical workloads"
+      default: true
+
+    - name: "Higher Performance"
+      iops_per_gb: 75
+      max_iops: 35000
+      throughput_mbps_per_gb: 0.6
+      max_throughput_mbps: 480
+      use_when: "Database data files, high-throughput applications"
+
+    - name: "Ultra High Performance"
+      iops_per_gb: 90
+      max_iops: 120000
+      throughput_mbps_per_gb: 0.72
+      max_throughput_mbps: 2680
+      use_when: "Extreme IOPS requirements, OLTP databases"
+      notes: "Only available with certain compute shapes"
+
+  sizing_guidance: |
+    1. Determine required IOPS (from AWR, CloudWatch, or application benchmarks)
+    2. Select tier that provides needed IOPS/GB ratio
+    3. Calculate minimum volume size: required_iops / iops_per_gb
+    4. Ensure volume size also covers storage capacity needs
+    5. If capacity-driven size exceeds IOPS needs, lower tier may suffice
+
+object_storage:
+  tiers:
+    - name: "Standard"
+      use_when: "Frequently accessed data"
+      first_10tb_per_month: "$0.0255/GB"
+
+    - name: "Infrequent Access"
+      use_when: "Accessed < once per month"
+      retrieval_fee: true
+      min_retention: "31 days"
+
+    - name: "Archive"
+      use_when: "Rarely accessed, long-term retention"
+      restore_time: "1 hour"
+      min_retention: "90 days"
+
+  auto_tiering: |
+    Enable auto-tiering to automatically move objects between Standard and
+    Infrequent Access based on access patterns. No retrieval fee when
+    auto-tiering moves data back to Standard.
+
+file_storage:
+  description: "OCI File Storage Service (NFS)"
+  performance: "Scales with file system size — larger = more IOPS/throughput"
+  iops_baseline: "Up to 50,000 IOPS"
+  throughput: "Up to 1.2 GB/s"
+  use_when:
+    - "Shared file system across multiple compute instances"
+    - "NFS-compatible workloads"
+    - "Kubernetes ReadWriteMany persistent volumes"
+  pricing: "$0.30/GB/month"

kb/sizing/storage-performance.yaml

@@ -0,0 +1,70 @@
+---
+last_verified: 2026-03-14
+description: Storage performance characteristics across OCI storage tiers.
+---
+
+storage_tiers:
+  adb_serverless:
+    type: "Exadata managed storage"
+    iops_random_read: "Up to 600K per ADB instance"
+    iops_random_write: "Workload dependent"
+    throughput: "Scales with OCPUs"
+    latency_read_us: "<200 (Smart Scan eligible)"
+    latency_write_us: "<500"
+    notes: "Performance scales with OCPU count, Exadata Smart Scan offloads queries"
+
+  exadata_storage:
+    type: "Exadata Smart Storage"
+    iops_random_read: "Up to 6.4M per rack (X9M)"
+    throughput_gbps: "Up to 100 GB/s (X9M)"
+    smart_scan: true
+    flash_cache: true
+    hcc: true
+    notes: "Highest performance tier, Smart Scan can offload full table scans"
+
+  block_volume_balanced:
+    type: "Block Volume (Balanced)"
+    iops_per_gb: 60
+    max_iops: 25000
+    throughput_kbps_per_gb: 480
+    max_throughput_mbps: 480
+    latency_us: "Sub-millisecond"
+
+  block_volume_higher_performance:
+    type: "Block Volume (Higher Performance)"
+    iops_per_gb: 75
+    max_iops: 35000
+    throughput_kbps_per_gb: 600
+    max_throughput_mbps: 600
+    latency_us: "Sub-millisecond"
+
+  block_volume_uhp:
+    type: "Block Volume (Ultra High Performance)"
+    max_iops: 450000
+    max_throughput_mbps: 2680
+    notes: "Requires UHP-enabled shapes"
+
+  object_storage:
+    type: "Object Storage"
+    throughput: "High (parallel multipart uploads)"
+    latency: "Milliseconds (first byte)"
+    use_for: "Backups, archives, unstructured data"
+    not_for: "Random IOPS workloads"
+
+  file_storage:
+    type: "File Storage (NFS)"
+    max_iops: 25000
+    max_throughput_mbps: 1200
+    latency: "Sub-millisecond"
+    use_for: "Shared file access, NFS workloads"
+
+sizing_from_source:
+  exadata_to_adb:
+    notes: "ADB-S on Exadata infra — performance is comparable or better"
+    recommendation: "Map directly, ADB auto-tunes storage"
+  physical_server_to_block_volume:
+    notes: "Match IOPS and throughput requirements to block volume tier"
+    recommendation: "Use Higher Performance for database, Balanced for app tier"
+  san_to_block_volume:
+    notes: "SAN IOPS vary widely — get actual metrics"
+    recommendation: "Size for P95 IOPS, test with fio before migration"