Database-Aware Workload Coverage

Database-Aware Disaster Recovery and Migration

Yorigu DB System Workloads extends Disaster Recovery and Migration beyond generic Machine movement. Engine-aware discovery, alignment checks, database consistency, validation, cutover readiness, and recovery state stay visible for Oracle Database, Microsoft SQL Server, PostgreSQL, MySQL, MongoDB, and SAP HANA workloads.

A DB System is one source database deployment: a standalone server, a RAC cluster across hosts, or a single server hosting many databases, counted as one. When database workloads run on discovered machines, DB Systems adds engine-aware discovery, alignment checks, and target-host placement decisions.

Supported Database Engines

DB-aware coverage for the engines operations teams actually run

Yorigu DB System Workloads supports database-aware planning, validation, and recovery or cutover readiness for Oracle Database, Microsoft SQL Server, PostgreSQL, MySQL, MongoDB, and SAP HANA. The engine list is intentionally visible because DB-aware scope should be explicit before a recovery or migration design is discussed.

Oracle DatabaseMicrosoft SQL ServerPostgreSQLMySQLMongoDBSAP HANA

Version ranges and deployment topologies are confirmed per engagement.

Database Consistency

Application-Consistent Recovery

For mission-critical Oracle Database, SQL Server, PostgreSQL, MySQL, MongoDB, and SAP HANA systems, the goal is a consistent, usable database on the target side, validated as part of the workflow.

Source discovery

Engine-aware evidence before placement

DB Systems identifies database engine signals, topology and footprint evidence, source alignment risks, and the target host model before cutover or failover planning proceeds.

Coverage

Where DB System Workloads Applies

  • Physical database servers
  • Virtual Machines running database workloads, including machines discovered from VMware source inventory
  • Oracle Database, Microsoft SQL Server, PostgreSQL, MySQL, MongoDB, and SAP HANA environments
  • Disaster Recovery workflows that need validation and failback readiness
  • Migration workflows that need dry-run, cutover, and rollback planning

Yorigu Disaster Recovery

DB System Workloads in Disaster Recovery

Recovery State

Recovery state remains visible before a real failover event.

Replication Alignment

Replication, alignment status, guarded failover readiness, and target-host placement assumptions stay visible during normal operation.

Validation Evidence

Validation results are tracked as part of the recovery lifecycle.

Failover Readiness

Failover readiness reflects tracked workflow state and validation results.

Failback Preparation

Failback readiness remains visible before production ownership moves back.

Yorigu Migrate

DB System Workloads in Migration

Target Assessment

The source database environment is assessed with engine-aware discovery, footprint evidence, alignment checks, and target-host placement decisions against the selected target platform.

Wave Planning

Workload waves are planned before committing cutover.

Dry-Run Readiness

Dry-run state is reached before any production cutover.

Cutover Planning

Cutover planning keeps readiness, sequencing, and validation in one workflow.

Rollback Visibility

Rollback planning remains visible for post-cutover decisions.

Platform Scope

Source-Independent Database Coverage

DB System Workloads applies across supported Yorigu targets and source form factors. It can cover Physical database servers, VM-hosted database systems, and customer-managed database environments under Database-Aware packaging.

SAP HANA Target Topology

SAP HANA

For SAP HANA, DB System Workloads can also work with an external HANA DR host instead of forcing the database target into the same VM target platform. Yorigu manages HANA System Replication readiness, alignment monitoring, and guarded takeover, while the customer remains responsible for the underlying SAP-supported platform or adopted HANA DR topology.

Packaging

Scoped by DB System

DB System Workloads can be included when database-aware workflow coverage is required. Capacity is scoped by DB System rather than by individual database, so environments with many small databases on the same server can be evaluated as one operational system.

This keeps packaging aligned with the operational DB System. A server hosting many small databases counts as one DB System for scoping.

Solutions

DB-aware use cases

Use the Solutions page to compare when DB System coverage is the main planning dimension across recovery and migration paths.

View DB-Aware Use Cases