Oracle Zero Data Loss Recovery Appliance

Bobby Campbell
Kilo Sage

How are you classing this?

 

The ZDLRA is an engineered system for data protection of Oracle databases.  Parts of the system are non-discoverable, and it's been a struggle to figure out how to accurately capture the entity in CMDB.

 

I'm thinking of something like a Technical Service that depends on the infrastructure components.

 

One deployed Service Instance (or would it be a Service Offering?) per data center:

 

Data Center #1

- Hardware Rack

-- Compute Nodes (discoverable)

-- Exadata Storage Servers (not discoverable)

-- InfiniBand Switches

 

Data Center #2

- Hardware Rack

-- Compute Nodes (discoverable)

-- Exadata Storage Servers (not discoverable)

-- InfiniBand Switches

 

But it feels like I'm missing something.  How would you track this type of system in the CMDB, attempting to align with CSDM?  Are there other details I should be thinking about that might guide me to the correct approach?  I'm reviewing the CSDM Data Model examples and latest White Paper, but if this type of system is addressed, it may be over my head.

 

 

1 ACCEPTED SOLUTION

AJ-TechTrek
Giga Sage
Giga Sage

Hi @Bobby Campbell ,

 

Step 1 – Understand What You’re Modeling
ZDLRA is:
* An engineered system dedicated to data protection of Oracle databases.
* It’s not just hardware — it’s a technical capability with multiple infrastructure components.
* Some CIs are discoverable (compute nodes) and others not discoverable (Exadata storage, InfiniBand).

 

Step 2 – CSDM Lens
In CSDM, you want to separate:
1. What the business consumes → Services / Service Offerings
2. What the technology runs on → Application Services, Application Components, Infrastructure CIs

Suggested Mapping


A. Technical Service
* Create a Technical Service in cmdb_ci_service_technical
Example: "Oracle ZDLRA Data Protection Service"
* Purpose: Represents the capability ZDLRA provides, not tied to a specific data center.
* Owned by: DB Infrastructure / Backup Team


B. Service Offerings / Service Instances
* For each data center, define:
* Service Offering (if these are distinct offerings with SLAs, costs, etc.) OR
* Service Instance (if it’s the same offering deployed in multiple locations).


* Example:
* Service Instance – ZDLRA @ DC1
* Service Instance – ZDLRA @ DC2


C. Underlying CIs (Infrastructure Layer)
* Hardware Rack → cmdb_ci_rack
* Compute Nodes → cmdb_ci_computer (discovered)
* Exadata Storage → cmdb_ci_storage_server (manual entry)
* InfiniBand Switches → cmdb_ci_network (manual entry if not discoverable)

 

Step 3 – Relationships
Use Dependency Relationships:
* Technical Service → depends on Service Instances
* Service Instance → runs on Hardware Rack (and other infra CIs)
* Racks contain compute nodes, storage, and switches
* Non-discoverable components entered manually but still linked into the model.

 

Relationship Example for DC1
Technical Service: Oracle ZDLRA Data Protection Service
└── Service Instance: ZDLRA @ DC1
├── Hardware Rack (cmdb_ci_rack)
│ ├── Compute Nodes (discovered)
│ ├── Exadata Storage (manual CI)
│ └── InfiniBand Switches (manual CI)

 

Step 4 – Non-Discoverable Components
For items like Exadata Storage or InfiniBand Switches:
* Create CIs manually in the appropriate class.
* Set Discovery Source = Manual Entry.
* Link them to the service and rack to keep the dependency chain complete.

 

Step 5 – Additional Considerations
* Data Certification – Ensure manually added CIs are reviewed periodically.
* Attributes – Capture serial numbers, firmware versions, capacity, etc., for support and audit.
* Application Service (optional) – If backup software or DB tools run on top of ZDLRA, model that in cmdb_ci_appl_service and link to the Technical Service.

 

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

View solution in original post

2 REPLIES 2

AJ-TechTrek
Giga Sage
Giga Sage

Hi @Bobby Campbell ,

 

Step 1 – Understand What You’re Modeling
ZDLRA is:
* An engineered system dedicated to data protection of Oracle databases.
* It’s not just hardware — it’s a technical capability with multiple infrastructure components.
* Some CIs are discoverable (compute nodes) and others not discoverable (Exadata storage, InfiniBand).

 

Step 2 – CSDM Lens
In CSDM, you want to separate:
1. What the business consumes → Services / Service Offerings
2. What the technology runs on → Application Services, Application Components, Infrastructure CIs

Suggested Mapping


A. Technical Service
* Create a Technical Service in cmdb_ci_service_technical
Example: "Oracle ZDLRA Data Protection Service"
* Purpose: Represents the capability ZDLRA provides, not tied to a specific data center.
* Owned by: DB Infrastructure / Backup Team


B. Service Offerings / Service Instances
* For each data center, define:
* Service Offering (if these are distinct offerings with SLAs, costs, etc.) OR
* Service Instance (if it’s the same offering deployed in multiple locations).


* Example:
* Service Instance – ZDLRA @ DC1
* Service Instance – ZDLRA @ DC2


C. Underlying CIs (Infrastructure Layer)
* Hardware Rack → cmdb_ci_rack
* Compute Nodes → cmdb_ci_computer (discovered)
* Exadata Storage → cmdb_ci_storage_server (manual entry)
* InfiniBand Switches → cmdb_ci_network (manual entry if not discoverable)

 

Step 3 – Relationships
Use Dependency Relationships:
* Technical Service → depends on Service Instances
* Service Instance → runs on Hardware Rack (and other infra CIs)
* Racks contain compute nodes, storage, and switches
* Non-discoverable components entered manually but still linked into the model.

 

Relationship Example for DC1
Technical Service: Oracle ZDLRA Data Protection Service
└── Service Instance: ZDLRA @ DC1
├── Hardware Rack (cmdb_ci_rack)
│ ├── Compute Nodes (discovered)
│ ├── Exadata Storage (manual CI)
│ └── InfiniBand Switches (manual CI)

 

Step 4 – Non-Discoverable Components
For items like Exadata Storage or InfiniBand Switches:
* Create CIs manually in the appropriate class.
* Set Discovery Source = Manual Entry.
* Link them to the service and rack to keep the dependency chain complete.

 

Step 5 – Additional Considerations
* Data Certification – Ensure manually added CIs are reviewed periodically.
* Attributes – Capture serial numbers, firmware versions, capacity, etc., for support and audit.
* Application Service (optional) – If backup software or DB tools run on top of ZDLRA, model that in cmdb_ci_appl_service and link to the Technical Service.

 

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

Bobby Campbell
Kilo Sage

AJ, thank you for your detailed and insightful response.  It helps me and others think more clearly about this type of challenge.