Virtual Databases – Why They are Necessary, What Their Benefits Are, and How They are Displayed

Abstract

The concept of the virtual data-base improves the handling of DB information in the technical system information. This blog post describes:

• Former relationship of a technical system to a data-base system without virtual DB
• Problems occurring without virtual DB
  • … for multiple components in 1 DB system
  • … for replication scenarios
• New relationship of technical systems to DB systems
• SAP Host Agent (SHA) DB monitoring
• Landscape data after the introduction of virtual data-bases
• Scenarios including virtual data-bases:
  • System monitoring scenario
  • Complex scenarios
• Display of virtual DBs in the LMDB Technical System Editor

Former Relationship of a Technical Systems to a DB System

Figure 1: Landscape data without virtual data-bases – example: Technical system (AS ABAP with Data-Supplier transaction RZ70 and Diagnostics Agent.

The former registration of data-bases worked as follows:

• Before using virtual data-bases, via transaction RZ70 both data-base system and technical system AS ABAP were registered and linked. The data-base system got the same virtual hostname as the technical system (see SAP Note 1052122 – Host names in SLD and LMDB).
• Outside Discovery via the Diagnostics Agent delivered information on data-base system (DB system) and retrieved the 1^st (!) existing data-base (e.g. the one registered via RZ70) and linked it to the technical system.
  The DB system’s name was composed of DB Name, DB Type and one DB Host from a list.
  DBs were searched by these names and, in some cases, matched with e.g. the DB registered via RZ70 and its information was enriched. The hostname is defining the name of the DB. After the 1. match with a host the search ended.
• By that time, it wasn’t necessary to have an abstract relationship between AS ABAP system and DB system. For an SAP Solution Manager with DBA Cockpit Monitoring, this is still not needed, since the DBA Cockpit directly connects to the DB. With the introduction of virtual data-bases, this concept was no longer sufficient.

Problem Occurring without Virtual DB for Multiple Components in 1 DB System

Figure 2: A correct description – example: Technical system (AS ABAP) – with multiple components in one data-base (MCOD) is not possible without virtual data-bases.

Because of the introduction of Multiple Components in one DB, the need to enhance the model emerged: Without it, it was not possible with the former model, to describe a landscape having two systems AS ABAP with differing host names sharing one DB system.

Problem Occurring without Virtual DB for Replication Scenarios

Figure 3: Data without using virtual data-bases – example technical system AS ABAP

Without the virtual DB concept, the replication relation couldn’t be represented in the LMDB in a way that the switch to the new physical DB would be correctly interpreted by LMDB client applications, such as monitoring.

New Relationship of Technical Systems to Data-Base Systems

SAP Host Agent (SHA) DB Monitoring

Figure 4: Data with SAP Host Agent DB Monitoring.

Note: Transaction RZ70 does not deliver information about the physical host / DB system.

In the LMDB the linking between the virtual and the physical database is done using association SAP_IdenticalDatabaseSystem, so that in this context, the information gathered on physical DB can be assigned to the right technical system.

Landscape Data after the Introduction of Virtual Data-Bases

Figure 5: Data when using virtual data-bases – example: Technical system AS ABAP (MCOD).

After the Introduction of virtual data-bases, RZ70 delivers data of the technical system AS ABAP and a data-base with its virtual host (in our example ABC with a different host each).
The data-supplier Outside Discovery via the Host Agent delivers data on a data-base, in our example ABC with a physical host). The physical data-base ABC is linked to the virtual data-bases ABC delivered by the two technical systems transactions RZ70 via association SAP_IdenticalDatabaseSystem.

Also see SAP Note 2499629 – Manual activities in LMDB when switching the Outside Discovery by Diagnostic Agent to Outside Discovery by SAP Host Agent.

Scenarios including Virtual Data-Bases

The Replication Scenario

After the introduction of virtual data-bases the replication scenario can be handled as shown in this example:

• A physical data-base ABC with physical host host_2 for the replication is delivered by the HANA data-supplier and linked to the secondary DB by association SAP_DatabaseReplicationDependency (see figure 6a)
  The linked data-base ABC with physical host host_1 becomes the primary DB.
• Replication scenario – e.g. at a DB take-over by the secondary DB in the case of a problem with the primary DB (often temporarily): The former secondary DB becomes the primary DB and consequently also becomes the physical DB related to the virtual DB (see figure 6b).

Figure 6a: Data when using virtual data-bases – example: Replication of a technical system AS ABAP.

This happens by switching virtualization to the other physical host and (temporarily, until DB system ABC on host_1 is available again) switch off the replication (using associations SAP_IdenticalDatabaseSystem and SAP_DatabaseReplicationDependency):

Figure 6b: Status during take-over in case of a DB problem.

System Monitoring Scenario

The following shows primary DB and secondary DB in a monitoring UI:

Screenshot of a monitoring UI of a virtual DB with 3 physical data-bases.

If the physical DB had to be replaced (temporarily), this is handled automatically by using the virtual DB concept. All metrics can be kept.
The reconfiguration after a take-over works automatically for SAP HANA.

Complex Scenarios

Complex Scenarios Including Tertiary DBs

Figure 8: Landscape data after introduction of virtual DBs – example: SAP HANA.

Here, we see a HANA-DB with a technical system AS ABAP and 3 Sites:

• Site_A: 1 primary DB on host host_A
• Site_B: 1 secondary DB on host host_B
• Site_C: 1 tertiary DB on host host_C

Upon a data-base take-over from Site_A over to Site_B:

• The replication from Site_A to Site_B is deleted
• The association SAP_IdenticalDatabase is switched to Site_B:
  Site_B becomes the primary DB, automatically.
• Site C becomes the secondary DB.

Advantages:

• Even if the physical DB had to be replaced, monitoring. All metrics are kept.
• Site_A can be added again, later.

HANA Data-Bases in Multi DB Replication Scenarios

Figure 9: Multi DB replication scenario.

For a HANA Multi DB Replication with tenants, one more layer has been added:
A tenant is the view of a customer system on a DB or DB instances, respectively.

Display of Virtual DBs in the LMDB Technical System Editor

Virtual DBs are shown in LMDB of SAP Solution Manager 7.2 and Focused Run for SAP Solution Manager:

Figure 10: Physical SAP HANA DB (BZT) and associated virtual DBs (BZT00001).

Further Information

For information on configuring HANA and virtual databases, see:

• SAP Help Portal (latest versions are shown; choose another version, if required):
  • Configuring SAP HANA for System Replication Technical Scenario in SAP Solution Manager
  • SAP HANA Administration Guide explaining the use of SAP Solution Manager for SAP HANA Administration
• SAP Support Portal: SLD Registration for SAP HANA SR Systems
• SAP Archive: For scale out scenarios, see SAP HANAä Host Auto-Failover 

For information on landscape data, see Get the Status of Your IT Landscape – Data in SLD, LMDB, and SAP Support Portal, and Its Verification.