Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

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

wolf_hengevoss
Active Participant
‎01-28-2020 1:27 PM

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 1st (!) 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 Agen....

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:

For information on landscape data, see .
2 Comments
Labels in this area
Popular Blog Posts