Domain 4: NoSQL Database Service (20%)

Domain 4 of the 1Z0-1093-25 Oracle AI Cloud Database Services 2025 Professional exam covers Oracle NoSQL Database Cloud Service (NDCS). At 20% of the exam this is one of the heaviest domains, translating to roughly 10 questions out of 50. You must understand the data models, capacity model, security, multi-region replication, query language, and SDK ecosystem.

1. Service Overview and Architecture

Oracle NoSQL Database Cloud Service is a fully managed, serverless NoSQL database running on Gen 2 OCI infrastructure. It provides predictable single-digit millisecond latency at any scale with zero administration of servers, patching, or upgrades. (NDCS Features)

Architecture

NDCS uses a sharded (shared-nothing) architecture that distributes data uniformly across multiple shards in a cluster. Within each shard, storage nodes are replicated across multiple Availability Domains (ADs) or Fault Domains (FDs) to provide high availability, rapid failover, and load balancing. There is zero single point of failure. (Oracle NoSQL Technologies)

Key architectural points:

• Data is automatically partitioned across shards using the shard key portion of the primary key
• Rows sharing the same shard key are co-located on the same physical shard
• Replication across ADs/FDs is transparent; failover is automatic
• Oracle handles all infrastructure: hardware, software, security patching, monitoring, and upgrades

Responsibility Model

Source: NDCS Features

Exam trap: Backups are the customer's responsibility. Oracle provides the NoSQL Migrator tool to export data to OCI Object Storage, but scheduling and executing backups is not automatic. This contrasts with Autonomous Database where automatic backups are Oracle-managed.

2. Data Models and Table Types

NDCS supports three data models through a unified table API. (NDCS Features)

Table Types

Source: Console Table Creation, NDCS Features

Table Hierarchies (Parent-Child)

Child tables enable data normalization with co-located access:

• Child rows are stored on the same shard as their parent (inherited shard key)
• Enables efficient left outer joins between parent and child
• writeMultiple API provides ACID transactions across parent and child tables
• Child inherits capacity and pricing model from the top-level parent
• Child tables count against the tenancy table limit
• Metrics are aggregated at the parent level only

Source: Console Table Creation

Exam trap: To access a child table, you need privileges on both the child AND the parent. Having INSERT on the child but no privilege on the parent will fail.

3. Supported Data Types

NDCS supports a rich set of data types for fixed-schema columns. (NDCS Reference)

Source: NDCS Reference

Best practice from Oracle: Use data types in this order of preference: INTEGER, LONG, FLOAT, DOUBLE, NUMBER. Avoid NUMBER unless necessary because it is the most expensive in both storage and processing.

Exam trap: JSON columns carry self-describing metadata overhead per document. Fixed-schema tables add exactly 1 byte overhead per record. If a question asks about storage efficiency, fixed-schema wins over JSON.

4. Table Design: Primary Keys, Shard Keys, and TTL

Primary Key Design

Every table requires a primary key. The primary key uniquely identifies each row and determines how data is distributed across shards.

CREATE TABLE IF NOT EXISTS products (
    product_id STRING,
    category STRING,
    details JSON,
    PRIMARY KEY(SHARD(category), product_id)
)

• Maximum primary key size: 64 bytes (NDCS Limits)
• Composite primary keys supported (multiple columns)
• Primary key columns are ordered; order matters for queries

Shard Key Design

The shard key is a subset of the primary key columns that determines which shard stores a row. Rows with the same shard key value are co-located.

PRIMARY KEY(SHARD(category), product_id)
-- 'category' is the shard key
-- Rows with same category value are co-located

Key shard key principles:

• Shard key determines data distribution across the cluster
• Co-located data enables efficient single-partition queries and ACID transactions
• A query that includes the complete shard key in the WHERE clause executes on a single partition (cheapest query type)
• Without the shard key, queries fan out to all partitions or all shards (expensive)

Source: Console Table Creation, Capacity Estimation

Exam trap: Choosing a shard key with low cardinality (few distinct values) creates hot spots. Choosing a shard key with extremely high cardinality (e.g., UUID) spreads data evenly but prevents co-located queries. The exam tests understanding of this trade-off.

Time-to-Live (TTL)

TTL specifies how long rows remain accessible before automatic expiration.

CREATE TABLE sensor_data (...) USING TTL 7 days
ALTER TABLE sensor_data USING TTL 30 days

• Set at table level or overridden per row
• Units: hours or days
• Default: 0 (no expiration)
• Updating table-level TTL does NOT retroactively affect existing rows; applies only to new rows or rows without a row-level override
• In Global Active Tables, expiration is replicated as an absolute timestamp, so rows expire simultaneously across all regions

Source: NDCS Reference, Global Active Tables

5. Capacity Model: Read Units, Write Units, and Storage

This is the most exam-critical section. Oracle tests capacity calculation knowledge heavily.

Unit Definitions

Source: NDCS Limits, Capacity Estimation

Consistency and Cost

Exam trap: Absolute consistency reads cost exactly 2x eventual consistency. A 1.5 KB record costs 2 RU (eventual) or 4 RU (absolute). The rounding happens first (1.5 KB rounds to 2 KB = 2 RU), then the consistency multiplier applies (2 RU x 2 = 4 RU for absolute).

Write Cost with Indexes

Secondary indexes add write overhead. When a record is modified:

Write Units = record_size + (1 KB x number_of_indexes_affected)

Example: Updating a 1 KB record in a table with 1 secondary index costs:

• Old record (1 KB) + New record (1 KB) + Index update (1 KB) = 3 WU for the update
• Delete operations also consume WU for index cleanup

Source: Capacity Estimation

Additional Cost Factors

Provisioned vs. On-Demand Capacity

Source: NDCS Limits, NDCS Features

Throughput Change Limits

• Increases: Unlimited per day
• Decreases: Up to 4 per 24-hour period
• Mode change (Provisioned to/from On-Demand): Once per day

Exam trap: You can increase provisioned capacity unlimited times, but decreases are limited to 4 per day. This is a common trick question.

6. Service Limits

Source: NDCS Limits

Most limits are customizable via a Service Limits Update request in the OCI Console.

Exam trap: The default batch limit for query execution is 2,000 read units (~2 MB of data). This can only be decreased, not increased, via query-level options.

7. Always Free Tier

Inactivity Deletion Policy

Reactivation: Any DML operation (get, put, delete on rows) reactivates the table. DDL operations (ALTER TABLE, CREATE INDEX) do NOT count as activity.

Source: NDCS Features

Exam trap: Always Free tables are singleton only (no Global Active Tables), capacity is fixed (cannot be changed), and they are auto-deleted after 90 days of inactivity. DDL operations do not count as activity for preventing deletion.

8. Security Model

Encryption

Source: NDCS Features

IAM Policies

NDCS uses OCI IAM for all access control. Three resource types are controlled independently. (Access Management)

Verbs and Permissions

Policy Syntax Examples

-- Tenancy-wide full access
allow group Admins to manage nosql-family in tenancy

-- Compartment-scoped read access
allow group Analytics to read nosql-rows in compartment Production

-- Table-specific row access (row-level security)
allow group DevTeam to manage nosql-rows in compartment Dev
    where target.nosql-table.name = 'customer'

-- Specific permission control
allow group Ops to manage nosql-tables in compartment Dev
    where any {request.permission = 'NOSQL_TABLE_CREATE',
               request.permission = 'NOSQL_TABLE_DROP'}

Cross-Tenancy Access

NDCS supports cross-tenancy access using three policy verbs:

Source: Access Management

Auditing

Oracle logs all DDL API calls to NoSQL Database tables. Logs are available to customers for audit purposes. (NDCS Features)

Exam trap: Row-level security is implemented via IAM policy conditions (e.g., where target.nosql-table.name = 'tablename'), not through a separate row-level security mechanism inside the database. This is fundamentally different from relational database row-level security (VPD/FGAC).

9. Secondary Indexes

NDCS supports up to 5 secondary indexes per table (customizable). (NDCS Limits)

-- Index on a fixed-schema column
CREATE INDEX IF NOT EXISTS idx_category ON products (category)

-- Index on a JSON field (must specify type)
CREATE INDEX IF NOT EXISTS idx_screen ON products
    (details.display.screenSize AS STRING)

Index Characteristics

Query Distribution with Indexes

Source: NDCS Reference, Capacity Estimation

Exam trap: Index lookups themselves are free (no separate RU charge for the index scan), but reading the resulting rows consumes RU normally. A "covering index" query avoids the row fetch entirely, making it the cheapest indexed query.

10. Query Language

NDCS uses a SQL-like query language (not full SQL). (NDCS Reference)

Supported Syntax

SELECT <expression>
FROM <table_name>
[WHERE <expression>]
[GROUP BY <expression>]
[ORDER BY <expression> [ASC|DESC]]
[LIMIT <number>]
[OFFSET <number>]

Supported Aggregate Functions

• count(*), count(expr)
• sum(expr)
• avg(expr)
• min(expr)
• max(expr)

Built-in Functions

• modification_time($row) -- row modification timestamp
• expiration_time($row) -- row TTL expiration time
• creation_time($row) -- row creation timestamp
• remaining_days($row) -- days until TTL expiration

UPDATE Syntax

UPDATE products $p
    SET TTL 30 DAYS
    WHERE id = 'prod_123'
    RETURNING remaining_days($p) AS Expires

What is NOT Supported

• JOINs (except parent-child left outer joins via table hierarchies)
• Subqueries
• CASE expressions in SELECT clause
• Nested aggregate functions
• DESCRIBE / SHOW TABLE statements
• Full-text indexes
• User/role management within the database

Source: NDCS Reference

Exam trap: NDCS query language looks like SQL but has significant limitations. No JOINs between unrelated tables, no subqueries, no CASE in SELECT. The only join type is a left outer join between parent and child tables in a hierarchy.

11. Global Active Tables (Multi-Region Replication)

Global Active Tables provide active-active multi-region replication. Any singleton table can become a Global Active Table by adding a regional replica. (Global Active Tables)

How It Works

1. Create a singleton table in a region
2. Freeze the table schema (change state from Mutable to Frozen)
3. Add a regional table replica in another region
4. Existing data is copied to the new replica (tracked as initialization percentage)
5. Once initialization reaches 100%, DML is allowed on the new replica
6. All subsequent writes replicate asynchronously across all regions

What Gets Replicated

• Table schema and secondary indexes
• All row data
• Storage capacity (identical across all replicas)
• Table default TTL (replicated as absolute timestamp)
• Read and write capacity defaults (can be customized per region)

Conflict Resolution

Last-writer-wins based on timestamp: When multiple regions update the same primary key, the write with the latest timestamp wins. Same rule applies to TTL updates.

Scope of Operations

Schema Changes on Global Active Tables

To modify the schema of a Global Active Table:

1. Drop ALL regional replicas
2. Alter the table schema
3. Re-add regional replicas (data automatically re-populated)

Best practice: Include at least one JSON column to allow schema flexibility without needing to drop replicas.

Identity Columns and Global Active Tables

• Standard GENERATED ALWAYS AS IDENTITY is NOT suitable for Global Active Tables (not guaranteed unique across regions)
• Use UUID as primary key instead for global uniqueness

Required IAM Permissions

Limitations

• Schema must be frozen before adding replicas
• Storage capacity must be identical across all regions
• ACID transactions are local to the region where the write occurred
• Eventual consistency for cross-region reads
• Always Free tables cannot be Global Active Tables
• Dedicated/Hosted environments do not support Global Active Tables
• Compartment with the same name must exist in the receiver region

Source: Global Active Tables

Exam trap: Schema must be FROZEN before adding replicas. To change the schema, you must drop ALL replicas first, alter the table, then re-add replicas. This is a disruptive operation. The exam will test whether you know this requirement.

Exam trap: ACID transactions in Global Active Tables are local to one region only. Cross-region consistency is eventual. If a question asks about transaction guarantees in multi-region, the answer is "local ACID, eventual cross-region."

12. Table States and Lifecycle

Source: NDCS Reference

13. SDK and Development Ecosystem

NoSQL Database SDKs

NDCS provides dedicated SDKs in six languages. These are distinct from the general OCI SDKs and provide richer NoSQL-specific functionality. (NoSQL SDK Drivers)

Framework Integration

• Spring Data: Jakarta NoSQL and Eclipse TopLink compatibility
• OCI SDKs: REST-based alternative (Java, Python, JS, .NET, Go, Ruby, PL/SQL) with more limited NoSQL features

Key Advantage of NoSQL SDKs over OCI SDKs

NoSQL SDKs work with all three deployment targets using the same API:

1. Oracle NoSQL Database Cloud Service (production)
2. Oracle NoSQL Database on-premises (Enterprise/Community Edition)
3. Oracle NoSQL Cloud Simulator (local development)

Oracle NoSQL Cloud Simulator

The Cloud Simulator is a locally deployable instance that emulates the full NDCS API for development and testing:

• Requires Java 8 or higher
• Runs on localhost (default port 8080)
• Downloaded separately from the Oracle NoSQL OTN download page
• All SDKs can connect to it with simple configuration changes
• Ideal for CI/CD pipelines and local development without cloud costs

Source: NoSQL SDK Drivers

OCI Management Interfaces

Authentication Methods

Source: NDCS Overview

14. Backup and Restore

NDCS does not provide automatic backups. Backup and restore are customer responsibilities.

Approach

• Use the NoSQL Database Migrator tool to export table data to JSON or Parquet format
• Export targets: local files, OCI Object Storage, or AWS S3
• Import from: JSON, Parquet, CSV, MongoDB-formatted JSON, DynamoDB-formatted JSON
• The migrator operates at table granularity (one table per migration task)
• readUnitsPercent and writeUnitsPercent parameters control what percentage of provisioned capacity the migration uses (default: 90%)

Constraints During Migration

• NoSQL Migrator does not lock tables
• Avoid DML/DDL operations on the table during migration
• Avoid topology changes during migration

Source: NDCS Overview

Exam trap: Unlike Autonomous Database, NDCS has no automatic backup. You must implement your own backup strategy using the Migrator tool. This is a key differentiator the exam may test.

15. Integration with OCI Services

Oracle logs all DDL API calls for audit purposes, which integrates with OCI Audit service.

16. Dedicated (Hosted) Environment

For demanding workloads, NDCS offers a dedicated per-customer environment with higher limits. (NDCS Features)

Exam trap: Dedicated/Hosted environments do NOT support Global Active Tables. If a question combines "dedicated" and "multi-region replication," the answer involves this limitation.

17. Comparison with Other NoSQL Services (Context Only)

Exam trap: Oracle NDCS absolute consistency is roughly equivalent to DynamoDB strong consistency (both 2x read cost). But Cosmos DB has five consistency levels, which Oracle does not match. The exam will not test other cloud providers directly, but understanding the terminology helps eliminate wrong answers.

18. Quick-Reference: Key Numbers to Memorize

References

• Oracle NoSQL Database Cloud Service Documentation
• NDCS Features
• NDCS Limits
• NDCS Reference (Data Types, DDL, DML)
• Capacity Estimation
• Global Active Tables
• Access Management and Security
• Console Table Creation
• NoSQL SDK Drivers
• Planning Your Service
• Oracle NoSQL Technologies Overview
• 1Z0-1093-25 Exam Page