Who moved my topology.ini
Once I was working with 3 tier HANA replication I got this “beautiful” error:
Database was not coming up , Daemon process was dying. I can see errors in two trace files:
daemon_<hostname>.39200.000.trc:[11022]{-1}[-1/-1] 2015-08-05 16:37:43.337557 i Daemon TrexDaemon.cpp(13699) : comment file contains: nameserver: landscape ID mismatch between nameserver.ini/[landscape]/id (5548nnnn-7699-9b81-e100-0000ac113e11) and topology.ini (5548oooo-86a0-48fd-e100-0000ac113e0e)
nameserver_alert_<hostname>.trc:[4823]{-1}[-1/-1] 2015-08-05 16:25:58.683109 f NameServer TREXNameServer.cpp(03323) : landscape ID mismatch between nameserver.ini/[landscape]/id (5548nnnn-7699-9b81-e100-0000ac113e11) and topology.ini (5548oooo-86a0-48fd-e100-0000ac113e0e)
Finding nameserver.ini was not a big deal, we know about, or you can also refer to one of my earlier blog Hardware Key for the HANA Database
I started looking for topology.ini; the more I looked the more curious I got, and it was nowhere to be found.
I do found SAP giving us command to modify parameters in topology.ini for various issues or purposes. Examples mentioned in the notes 1649519, 1867324, 1950221, 1697613 and 2093572
- Remove the SAP HANA Statitisticsserver service entry from the topology. To do this, carry out the following command for every <host name> with an SAP HANA Statitisticsserver service:
ALTER SYSTEM ALTER CONFIGURATION (‘topology.ini’, ‘system’) UNSET (‘/host/<host name>’, ‘statisticsserver’) WITH RECONFIGURE
- Remove the SAP HANA XS service entry from the topology. To do this, carry out the following command for every <host name> with an SAP HANA XS service:
ALTER SYSTEM ALTER CONFIGURATION (‘topology.ini’, ‘system’) UNSET (‘/host/<host name>’, ‘xsengine’) WITH RECONFIGURE
I confirmed with SAP that its not a physical file, its more like a virtual one, the naming convention is still being carried till today which started from the other SAP product TREX.
That make some sense, but even though its not physical file, but HANA can relate/associate values to it, in some cases we can alter the content of this “ghost” file through ALTER command.
How to know what is the content of this file.
Here is the simple one:
login with <sid>adm on Hana server and execute -> cdpy
it will take you to the directory $DIR_INSTANCE/exe/python_support
on the command prompt you can type
$> python fullSystemInfoDump.py
it will take some time and create single zip file stuffed with all core files and traces and history of the world since big bang.
If you will unzip it you can find The Golden file : topology.txt
but just to get this file I hate to wait so long and get a bulky file. Instead I just need only topology.txt file.
Here is how to get only that file:
copy the file fullSystemInfoDump.py to zLeanSystemInfoDump.py
and modify like below
Original code ↑
Modified code ↑ (deleted few lines creating unwanted file for our case)
Here we can execute the command as shown in above screenshot, later we can unzip the output file to get topology.txt file.
This file contains good information at one place. its a good read.
To read my other blogs please follow the link Ishteyaque Ahmad
Regards.
thanks for the good information!
This is really very good information ,
Thanks buddy
Thank you~ it's very useful!
Thanks for this information. We are in a situation where we performed system copy from Prod to QA. Prod had 3 tier replication (Prim, HA, DR). Topology was carried over as part of system copy. We performed SR cleanup however information from topology is not removed. I have not come across any OSS notes to remove System Replication config. You blog helped us get closer to the issue. Thanks. Sanjay
At least in somewhat modern versions you can execute hdbnsutil -printTopology to get a readable version of HANA topology.
In newer versions there is also a json format kept up to date in the (master) host trace folder. (named nameserver_topology_<hostname>.json.