Raghuram Devarakonda · Apr 27, 2017

Is it possible to change GUID of an instance?


I am wondering if there is a way I can change the GUID of an instance. The use case is that I am restoring from a backup on an alternate host and start the instance there. However, the restored instance ends up with same GUID as that of source. Is there a way I can tell this newly restored instance to use a different GUID?



7 0 19 485
Log in or sign up to continue


By looking at the code of the InstanceGUID method in the %SYS.System class we can see where it's stored:

/// Returns instance GUID.
/// <br>
/// An instance GUID is a 16 byte (128 bit) globally unique identifier, assigned per instance of Cache installation.
ClassMethod InstanceGUID() As %String
    s ns="^^"_$zu(12)
    if ('$d(^[ns]SYS("INSTANCEGUID"))) Set ^[ns]SYS("INSTANCEGUID")=$system.Util.CreateGUID()

It's in ^SYS("INSTANCEGUID") in the CACHESYS database.

USER>w ##class(%SYS.System).InstanceGUID()
USER>w $zv
Cache for Windows (x86-32) 2016.2.1 (Build 803U) Wed Oct 26 2016 13:33:05 EDT

However I don't know what might happen if you change it. Best check with InterSystems.

Thanks for quick response.

I don't mind leaving the GUID untouched but then the question is, would it be alright for two instances (on different hosts) to have same GUID?

Do note that the restored instance is meant for test purposes and would usually be removed after the testing. 



If its just for testing then its fine.


I wrote my answer before reading yoyr comment. In this very case it seems that it's nothing should be done with GUID.

Happy testing!

Ok. I am going to leave it unchanged then.

But just out of curiosity, is it even possible to change the GUID of an instance? 



If you are curious, you may try to do it following John's hint, but if you didn't catch the idea, better do not.

Raghu, please consider accepting one of the answers by clicking the big checkmark alongside it.

I accepted your answer (thanks). BTW, is it possible to accept only one answer? I wanted to accept some others as well but the check mark is grayed out. Also, I don't see response from Alexey any more in this thread. Is it possible a response can be removed?

Hi, Raghu!

It is possible to mark only one answer as accepted at the moment. 

But if the situation like this would repeat we would think what to do. Sometimes question has more than one right answer.


Question may have more than one right answer.
Several answers may add some useful info to each other.
Complicated question may even collect several competiting answers. Who will be a judge?

I think we speak about only the checkbox near answer to mark any answer in a question as accepted. 

The judge is the topic starter of course.

The practical value of this checkbox option for the community members is:

1. At least one answer makes sense for the topic starter  (which is great BTW).

2. It signals that the question has the accepted answer and thus question disappears from unanswered feed filter.

But it doesn't negate the fact that other answers can be valuable. 

I think  everything great and this shouldn't be the cause to delete all the answers except the accepted one. 


Thanks Raghu. AFAIK the DC software only allows one answer to be accepted. It does allow answers to be deleted by their author, so I guess Alexey did that.

Thanks. I guess the big question is what impact such GUID change will have on the applications.

I think the idea of changing the ID of the instance is never a good idea whether it is ID or GUID.

While it's easy to change GUID following John's hint (if you understood the code, you already know which global node to kill, and it will be recreated on the next call), I wonder why do you want it? It seems that your instanse have migrated to another host, hense you may want to save all its requisites (including GUID) untouched. This GUID is not used by Cache itself, but may be used in some app data fields, so you may loose app level integrity.

PS. If you didn't understand the code, or are cautious to change system globals, you'd better deinstall Cache and re-install it into the same folder. System DBs would be totally rewritten while your app DBs as well as cache.cpf would be left as is.

The system that I work on used to use InterSystems' Object Synchronization feature quite heavily to keep multiple servers around the world in sync. There was one main server with about 5 "satellite" servers. The InstanceGUID of the main server was used to support Object Synchronization. When we had to clone the main server, in order to maintain proper syncing with the "satellite" servers, we reset the cloned instance with the instance GUID of the original system.

To quote a colleague at ISC:


The instance guid is used for more than one purpose but
it is supposed to be unique to the instance. Its probably best
after cloning an instance to set this to a new value (assuming the
cloned instance isn't supposed to replace the old instance). 


Since our clone was replacing the old one, we used the steps below to set the instanceGUID of the new instance with the GUID of the old one (and retired the old system).

<another quote>

The original purpose of this document was to list the steps to create an exact copy of the original Hermes machine, including its role as the object-synchronization partner with other servers  around the world. In order to fill this role, some additional steps were needed and these are listed here:

  1. Get the unique “InstanceGUID” of the LEGACY instance of Caché by running the following command on LEGACY. Save the GUID that results from the command; it will be used later:
  • HERMES>w ##class(%SYS.System).InstanceGUID()
  • 34411A13-6CF9-4511-AC7D-49C2CEC6DB5B
  1. Assign this value to the new Hermes instance on NEW by issuing the following commands in the Caché Terminal on NEW:
    • s ns = “^^”_$zu(12)
    • s ^[ns]SYS(“INSTANCEGUID”)=”<Guid from Step 3 above>”
    • w ##class(%SYS.system).InstanceGUID()

</another quote>

Note that this is  something that should be done unless really necessary, but it is possible.

My apologies, I realize that I answered the wrong question. 

When we created a system from a backup and wanted the new instance to have a different instanceGUID from the original system, we used the following command to give a copy of the system a new instanceGUID:

%SYS>s ^SYS("INSTANCEGUID")=##class(%SYSTEM.Util).CreateGUID()