Delphix Products

We've recently moved our Delphix engine from one server to a new one via replication and fail over, and we need to decommission the old engine and server, but not the VDBs, environments, etc, since those are now connected to the new engine the new server.  What is the best practice for doing that?  

Hello David,

Thank you for reaching out to the community.

We have documented here how to decommission a Delphix Engine: How to Decommission a Delphix Virtualization Engine (KBA5438)

Please let us know if this works for you.

Thanks

Adam

We've recently moved our Delphix engine from one server to a new one via replication and fail over, and we need to decommission the old engine and server, but not the VDBs, environments, etc, since those are now connected to the new engine the new server.  What is the best practice for doing that?  

Thanks Adam, but those are the procedures I was referring to- in my post.  Step 1, 2, and 3 are deleting all VDBs, dSources, and environments.  But we're not looking to delete those, they have just been moved to another server via the replication function.  If I try clicking delete on any of the VDB entries in the old engine, it seems to be reaching out to actually try to delete the VDB, which we don't want.

Hello David,

Thank you for reaching out to the community.

We have documented here how to decommission a Delphix Engine: How to Decommission a Delphix Virtualization Engine (KBA5438)

Please let us know if this works for you.

Thanks

Adam

We've recently moved our Delphix engine from one server to a new one via replication and fail over, and we need to decommission the old engine and server, but not the VDBs, environments, etc, since those are now connected to the new engine the new server.  What is the best practice for doing that?  

Hi David,

When you replicated and failed over, did you disable all of the VDBs and dSources on the source Delphix Engine ( https://documentation.delphix.com/docs/controlled-failover?highlight=controlled%20failover )?

If they were not disabled prior to the failover, both Delphix Engine's will think that they are actively managing the objects (dSources and VDBs). If you tried to delete a VDB while both engine's were managing them, it would delete the VDB from the host (SQL Server, Oracle, etc.) and remove the underlying references on the Delphix Engine where you performed the delete.

It would not touch the underlying reference and storage on the target replication engine and you could disable/enable the objects on the replication target engine to restart them.

If both Delphix Engine's think they are managing the objects, it is better to disable the objects (dSources and VDBs) on both engines, then delete them from the engine you want to decommission and then enable them on the new engine.

If you have any doubts about the current states, you might wish to open a support case and upload support bundles from the two Delphix Engines.

Thanks,

Neal

Thanks Adam, but those are the procedures I was referring to- in my post.  Step 1, 2, and 3 are deleting all VDBs, dSources, and environments.  But we're not looking to delete those, they have just been moved to another server via the replication function.  If I try clicking delete on any of the VDB entries in the old engine, it seems to be reaching out to actually try to delete the VDB, which we don't want.

Hello David,

Thank you for reaching out to the community.

We have documented here how to decommission a Delphix Engine: How to Decommission a Delphix Virtualization Engine (KBA5438)

Please let us know if this works for you.

Thanks

Adam

We've recently moved our Delphix engine from one server to a new one via replication and fail over, and we need to decommission the old engine and server, but not the VDBs, environments, etc, since those are now connected to the new engine the new server.  What is the best practice for doing that?  

Hi Neal,

All VDBs, dSources, and environments were disabled before we did the failover. I'm not sure how thing should look on the original server after failover, but I don't see anything different on that end.  No messages saying a failover was done, etc.  It looks exactly the same as it did when I disabled everything prior to the failover.  When I try to delete a VDB I'm getting ...

Hi David,

When you replicated and failed over, did you disable all of the VDBs and dSources on the source Delphix Engine ( https://documentation.delphix.com/docs/controlled-failover?highlight=controlled%20failover )?

If they were not disabled prior to the failover, both Delphix Engine's will think that they are actively managing the objects (dSources and VDBs). If you tried to delete a VDB while both engine's were managing them, it would delete the VDB from the host (SQL Server, Oracle, etc.) and remove the underlying references on the Delphix Engine where you performed the delete.

It would not touch the underlying reference and storage on the target replication engine and you could disable/enable the objects on the replication target engine to restart them.

If both Delphix Engine's think they are managing the objects, it is better to disable the objects (dSources and VDBs) on both engines, then delete them from the engine you want to decommission and then enable them on the new engine.

If you have any doubts about the current states, you might wish to open a support case and upload support bundles from the two Delphix Engines.

Thanks,

Neal

Thanks Adam, but those are the procedures I was referring to- in my post.  Step 1, 2, and 3 are deleting all VDBs, dSources, and environments.  But we're not looking to delete those, they have just been moved to another server via the replication function.  If I try clicking delete on any of the VDB entries in the old engine, it seems to be reaching out to actually try to delete the VDB, which we don't want.

Hello David,

Thank you for reaching out to the community.

We have documented here how to decommission a Delphix Engine: How to Decommission a Delphix Virtualization Engine (KBA5438)

Please let us know if this works for you.

Thanks

Adam

We've recently moved our Delphix engine from one server to a new one via replication and fail over, and we need to decommission the old engine and server, but not the VDBs, environments, etc, since those are now connected to the new engine the new server.  What is the best practice for doing that?  

Hi David,

That message means the environment is disabled and it won't allow you to delete the VDB while the environment is disabled.

You should be able to enable the environment and delete the VDB.

What does the status show for the VDB? Does it show it is stopped and the file system is unmounted?

Hi Neal,

All VDBs, dSources, and environments were disabled before we did the failover. I'm not sure how thing should look on the original server after failover, but I don't see anything different on that end.  No messages saying a failover was done, etc.  It looks exactly the same as it did when I disabled everything prior to the failover.  When I try to delete a VDB I'm getting ...

Hi David,

When you replicated and failed over, did you disable all of the VDBs and dSources on the source Delphix Engine ( https://documentation.delphix.com/docs/controlled-failover?highlight=controlled%20failover )?

If they were not disabled prior to the failover, both Delphix Engine's will think that they are actively managing the objects (dSources and VDBs). If you tried to delete a VDB while both engine's were managing them, it would delete the VDB from the host (SQL Server, Oracle, etc.) and remove the underlying references on the Delphix Engine where you performed the delete.

It would not touch the underlying reference and storage on the target replication engine and you could disable/enable the objects on the replication target engine to restart them.

If both Delphix Engine's think they are managing the objects, it is better to disable the objects (dSources and VDBs) on both engines, then delete them from the engine you want to decommission and then enable them on the new engine.

If you have any doubts about the current states, you might wish to open a support case and upload support bundles from the two Delphix Engines.

Thanks,

Neal

Thanks Adam, but those are the procedures I was referring to- in my post.  Step 1, 2, and 3 are deleting all VDBs, dSources, and environments.  But we're not looking to delete those, they have just been moved to another server via the replication function.  If I try clicking delete on any of the VDB entries in the old engine, it seems to be reaching out to actually try to delete the VDB, which we don't want.

Hello David,

Thank you for reaching out to the community.

We have documented here how to decommission a Delphix Engine: How to Decommission a Delphix Virtualization Engine (KBA5438)

Please let us know if this works for you.

Thanks

Adam

We've recently moved our Delphix engine from one server to a new one via replication and fail over, and we need to decommission the old engine and server, but not the VDBs, environments, etc, since those are now connected to the new engine the new server.  What is the best practice for doing that?  

Thanks Neal. The databases are stopped and File Systems is marked as unmounted.  I deleted one of the VDBs without an issue.

I do have another question.  The servers (old an new) are all using a common NAS share for the the Toolkit Path.  Do the environments need to be deleted before decommissioning?  If so, will deleting environments from the old server impact the new server since they are both pointing to the same NAS path?

Is there anything else that needs to be cleanup up before decommissioning?

Hi David,

That message means the environment is disabled and it won't allow you to delete the VDB while the environment is disabled.

You should be able to enable the environment and delete the VDB.

What does the status show for the VDB? Does it show it is stopped and the file system is unmounted?

Hi Neal,

All VDBs, dSources, and environments were disabled before we did the failover. I'm not sure how thing should look on the original server after failover, but I don't see anything different on that end.  No messages saying a failover was done, etc.  It looks exactly the same as it did when I disabled everything prior to the failover.  When I try to delete a VDB I'm getting ...

Hi David,

When you replicated and failed over, did you disable all of the VDBs and dSources on the source Delphix Engine ( https://documentation.delphix.com/docs/controlled-failover?highlight=controlled%20failover )?

If they were not disabled prior to the failover, both Delphix Engine's will think that they are actively managing the objects (dSources and VDBs). If you tried to delete a VDB while both engine's were managing them, it would delete the VDB from the host (SQL Server, Oracle, etc.) and remove the underlying references on the Delphix Engine where you performed the delete.

It would not touch the underlying reference and storage on the target replication engine and you could disable/enable the objects on the replication target engine to restart them.

If both Delphix Engine's think they are managing the objects, it is better to disable the objects (dSources and VDBs) on both engines, then delete them from the engine you want to decommission and then enable them on the new engine.

If you have any doubts about the current states, you might wish to open a support case and upload support bundles from the two Delphix Engines.

Thanks,

Neal

Thanks Adam, but those are the procedures I was referring to- in my post.  Step 1, 2, and 3 are deleting all VDBs, dSources, and environments.  But we're not looking to delete those, they have just been moved to another server via the replication function.  If I try clicking delete on any of the VDB entries in the old engine, it seems to be reaching out to actually try to delete the VDB, which we don't want.

Hello David,

Thank you for reaching out to the community.

We have documented here how to decommission a Delphix Engine: How to Decommission a Delphix Virtualization Engine (KBA5438)

Please let us know if this works for you.

Thanks

Adam

We've recently moved our Delphix engine from one server to a new one via replication and fail over, and we need to decommission the old engine and server, but not the VDBs, environments, etc, since those are now connected to the new engine the new server.  What is the best practice for doing that?  

Hi David,

If you go under the Help -> About menu for each Delphix Engine there will be a unique "Server ID" that identifies them (in my case it is "564dd38c-05a8-783a-1c96-16cb72ed2010").

Then if you look in your toolkit directory, each engine's unique toolkit directory will have a part of that string in it:

$ ls -ltr toolkit | grep 16cb72ed2010
drwxrwx---. 6 oracle  oinstall      61 Jan 20 15:16 Delphix_16cb72ed2010_02f63f3abb3b_13_host
drwxrwx---. 6 sybase  sybase        61 Feb  8 15:45 Delphix_16cb72ed2010_02f63f3abb3b_10_host
drwxrwxr-x. 5 sybase  sybase        49 Apr 27 11:11 564dd38c-05a8-783a-1c96-16cb72ed2010-staging-3
drwxrwxr-x. 5 sybase  sybase        49 Apr 28 13:38 564dd38c-05a8-783a-1c96-16cb72ed2010-staging-1
drwxrwxr-x. 5 sybase  sybase        49 May  2 15:24 564dd38c-05a8-783a-1c96-16cb72ed2010-staging-5
drwxrwxr-x. 8 sybase  sybase       144 May  2 15:25 Delphix_COMMON_16cb72ed2010_02f63f3abb3b_host
drwxrwxr-x. 5 sybase  sybase        49 May 11 12:25 564dd38c-05a8-783a-1c96-16cb72ed2010-vdb-15
drwxrwxr-x. 5 sybase  sybase        49 May 11 12:36 564dd38c-05a8-783a-1c96-16cb72ed2010-staging-6
drwxrwxr-x. 5 sybase  sybase        49 Jun  1 05:10 564dd38c-05a8-783a-1c96-16cb72ed2010-vdb-1

You can delete those directories after the engine is decomissioned.

I believe there is an outstanding request to clean those directories up that will be looked at for a future release of Delphix.

Thanks,

Neal

Thanks Neal. The databases are stopped and File Systems is marked as unmounted.  I deleted one of the VDBs without an issue.

I do have another question.  The servers (old an new) are all using a common NAS share for the the Toolkit Path.  Do the environments need to be deleted before decommissioning?  If so, will deleting environments from the old server impact the new server since they are both pointing to the same NAS path?

Is there anything else that needs to be cleanup up before decommissioning?

Hi David,

That message means the environment is disabled and it won't allow you to delete the VDB while the environment is disabled.

You should be able to enable the environment and delete the VDB.

What does the status show for the VDB? Does it show it is stopped and the file system is unmounted?

Hi Neal,

All VDBs, dSources, and environments were disabled before we did the failover. I'm not sure how thing should look on the original server after failover, but I don't see anything different on that end.  No messages saying a failover was done, etc.  It looks exactly the same as it did when I disabled everything prior to the failover.  When I try to delete a VDB I'm getting ...

Hi David,

When you replicated and failed over, did you disable all of the VDBs and dSources on the source Delphix Engine ( https://documentation.delphix.com/docs/controlled-failover?highlight=controlled%20failover )?

If they were not disabled prior to the failover, both Delphix Engine's will think that they are actively managing the objects (dSources and VDBs). If you tried to delete a VDB while both engine's were managing them, it would delete the VDB from the host (SQL Server, Oracle, etc.) and remove the underlying references on the Delphix Engine where you performed the delete.

It would not touch the underlying reference and storage on the target replication engine and you could disable/enable the objects on the replication target engine to restart them.

If both Delphix Engine's think they are managing the objects, it is better to disable the objects (dSources and VDBs) on both engines, then delete them from the engine you want to decommission and then enable them on the new engine.

If you have any doubts about the current states, you might wish to open a support case and upload support bundles from the two Delphix Engines.

Thanks,

Neal

Thanks Adam, but those are the procedures I was referring to- in my post.  Step 1, 2, and 3 are deleting all VDBs, dSources, and environments.  But we're not looking to delete those, they have just been moved to another server via the replication function.  If I try clicking delete on any of the VDB entries in the old engine, it seems to be reaching out to actually try to delete the VDB, which we don't want.

Hello David,

Thank you for reaching out to the community.

We have documented here how to decommission a Delphix Engine: How to Decommission a Delphix Virtualization Engine (KBA5438)

Please let us know if this works for you.

Thanks

Adam

We've recently moved our Delphix engine from one server to a new one via replication and fail over, and we need to decommission the old engine and server, but not the VDBs, environments, etc, since those are now connected to the new engine the new server.  What is the best practice for doing that?