Delphix Products

 View Only
  • 1.  dxtoolkit command to disable/shutdown all vdbs

    Posted 12-15-2022 12:22:00 PM
    Hello, might anyone have a dxtoolkit command that will disable/shutdown all vdbs in prep for a Delphix Virtualization engine reboot? And then an equivalent to enable them once the engine is available again? Thank you in advance for any tips/recommendations.

    Chris Patton
    Database Adminstrator, Sr

  • 2.  RE: dxtoolkit command to disable/shutdown all vdbs
    Best Answer

    Posted 12-16-2022 03:05:00 AM
    Hi Chris,

    You can use this command:

    dx_ctl_db -d engine -type VDB -action disable -parallel 4

    and it will be disable all VDB's from Delphix engine specify by -d parameter.
    After maintenance you can enable all VDB's using similar command

    dx_ctl_db -d engine -type VDB -action enable -parallel 4

    If for any reason you have a VDBs in different states - for example a few enabled and a few disabled
    and you want to keep that state you can use the following:

    to save a state and disable VDBs use this:

    dx_get_db_env -d engine -save /path/to/savefile 
    dx_ctl_db -d engine -type VDB -action disable -parallel 4

    to enable only VDB which were enabled before maintenance use:

    dx_ctl_db -d engine -restore /path/to/savefile 


    Marcin Przepiorowski
    Director, Technical Services

  • 3.  RE: dxtoolkit command to disable/shutdown all vdbs

    Posted 01-05-2023 02:12:00 PM
    Hello Marcin,

    I hope it's ok to jump on the back of Chris's original question. My question has a slightly different angle though in that I want to be able to shutdown / start all children dependencies of each dSource in one go i.e. VDBs & associated (selfservice) containers.

    So, to save existing state and disable all associated VDBs & containers, could I run something like this:

    1. dx_get_db_env -d engine_name -type dsource -dsource dSource_Name -save /path/to/savefile
    2. dx_ctl_db -d engine_name -type dsource -dsource dSource_Name -action disable -parallel 4
    And to restart/enable all that were enabled before (and in the correct order of precedence):
    dx_ctl_db -d engine_name -type dsource -dsource dSource_Name -restore /path/to/savefile


    Ola Omidiran
    Community Member
    Mizuho International plc UK

  • 4.  RE: dxtoolkit command to disable/shutdown all vdbs

    Posted 01-06-2023 04:57:00 AM
    Hello Ola,

    If you want to manage a VDBs based on dSource, you need to use this:

    dx_get_db_env -d engine_name -dsource dSource_Name 

    The name of filter -dsource can be misleading - it's selecting a VDB based on parent, so if you have a chain of VDBs
    like PROD1 -> VDB1 -> VDB2, dxtoolkit will do the following:

    -dsource PROD1 -> it will select VDB1
    -dsource VDB1 -> it will select VDB2

    If you want to disable all databases ( including all children, grant children and so on ), it's more complicated as 
    there is no single filter to that.

    You can list all databases hierarchy using dx_get_hierarchy -d engine_name -printhierarchy p2c
    but then you will need to parse output into comma separated list of VDBs to disable

    I will add a RFE for dxtoolkit to handle -dsource parameter better 


    Marcin Przepiorowski
    Director, Technical Services

  • 5.  RE: dxtoolkit command to disable/shutdown all vdbs

    Posted 01-17-2023 09:46:00 AM
    Thanks very much for the clarification Marcin. I thought as much until Chris's question came along ... I then thought perhaps I had missed something along the way.

    For the benefit of anyone that might find this useful, I will expand a bit more on our setup to make the following explanations clearer (I hope!) ...
    1. we have a certain number of delphix "environment" corresponding to distinct Sybase instances
    2. each environment could have one or more complete set(s) of "VDB"
    3. a VDB set comprises of 3 distinct databases that form a "group" with each db's dSource being one of three
    4. finally, a self-service container exist for each set of 3 VDBs or "group"
    For example:
    1. Environment - ADL_MURDB02_01
    2. VDB / databases - MIZ_VDB_DEV10_DM, MIZ_VDB_DEV10_MLC & MIZ_VDB_DEV10_MX
    3. dSources - dSource_DM, dSource_MLC & dSource_MX respectively
    4. Group / Container - DEV10
      • pls note that our group / container names are synonymous
    To shutdown/disable in an autonomous way, our automation does something along the lines of:
    1. iterate over a definitive list environments held in an array variable (for example)
    2. for each element identified, do the following
      • obtain list of all groups that exist in it by parsing out output of "dx_get_db_env -d ${delphix_engine} -hostenv e -envname ${_ase}"
      • for each identified group:
        • stop its associated (self-service) container by executing "dx_ctl_js_container -d ${delphix_engine} -container_name ${x} -action disable"
        • stop/disable associated VDBs belonging to the Group by executing "dx_ctl_db -d ${delphix_engine} -group ${x} -action disable"
    3. stop/disable the environment is everything else have been successfully stopped by executing "dx_ctl_env -d ${delphix_engine} -name ${_ase} -action disable"
    4. shutdown all 3 dSources with command similar to "dx_ctl_db -d ${delphix_engine} -envname <staging_env_name> -action disable"
    5. shutdown the <staging_env_name> env with command similar to "dx_ctl_env -d ${delphix_engine} -name <staging_env_name> -action disable"
    And of course, it goes without saying that appropriate error checking would be required between steps. To re-enable / restart all post maintenance window, it does everything in reverse e.g. starts staging env (if not already enabled), dSources, itereate over each environment and perform step 2 in reverse, etc.

    As you've already noted, I don't know if there is a definitive way of correctly working out dependency chains in situations that spans different delphix object types BUT any step towards that (e.g. proposed RFE) will be hugely useful and I look forward to seeing those changes in due course.

    Ola O.

    Ola Omidiran
    Community Member
    Mizuho International plc UK