Delphix Products

 View Only
  • 1.  Does replacing the physical databases with Virtual database,creates any issues in maintaining data bases for longer run

    Posted 04-29-2016 05:13:00 AM

    Does replacing the physical databases with Virtual database,creates any issues in maintaining data bases for longer run

    What all the maintenance activities we need to be prepared before migrating from physical to virtual databases ?

    Please let me know the activities to maintain the virtual data bases for longer ran..

    Could there be chances of crashing of Vdb's if  the calls are two high to the vdb's ?

    What all the precautionary measure to be taken while migrating from physical to Virtual  ?





  • 2.  RE: Does replacing the physical databases with Virtual database,creates any issues in maintaining data bases for longer run
    Best Answer

    Posted 04-29-2016 09:34:00 AM
    Questions in order:

    Q: Does replacing the physical databases with Virtual database,creates any issues in maintaining data bases for longer run?
    A: No. It actually is far easier to manage virtual databases as Delphix has built-in functionality to automatically backup every transaction of the database. And the backup data can be set to a retention policy. Plus you can refresh and rewind with the click of a button. It doesn't get any easier than that.

    Q: What all the maintenance activities we need to be prepared before migrating from physical to virtual databases?
    A: No maintenance activities. There are simple prerequisites, which are listed in our documentation (http://docs.delphix.com) and vary slightly for eachdatabase type.

    Q: Please let me know the activities to maintain the virtual data bases for longer run
    A: Set a retention policy for how long you want to keep historical data. Delete databases you no longer want to keep or archive. That's pretty much it. 

    Q: Could there be chances of crashing of Vdb's if  the calls are two high to the vdb's ?
    A: Sure. The VDB's still leverage an RDBMS, like Oracle. So, if you could crash a physical DB on an 2CPU/8GB instance of Oracle, it would also crash on a virtual database.

    Q: What all the precautionary measure to be taken while migrating from physical to Virtual?
    A: None really. Delphix is non-intrusive and non-disruptive. You can create a copy of the physical database without interrupting the physical database and use the virtual copies. If you wanted to replace the physical copy with the virtual copy, then once you tested the virtual copy and you are satisfied, you can point your applications to the VDB. 



  • 3.  RE: Does replacing the physical databases with Virtual database,creates any issues in maintaining data bases for longer run

    Posted 04-18-2019 02:41:00 PM
    Thanks for all thoughtful answers. I have one more question which has similar context. Is it good idea to performance testing on virtual database? does it give us true measure of application performance and database performance ?


  • 4.  RE: Does replacing the physical databases with Virtual database,creates any issues in maintaining data bases for longer run

    Posted 04-18-2019 03:12:00 PM
    Mahesh,

    Responding to your question about running INSERT statements in a hook...

    The best method with Oracle databases is the SQL*Plus command-line program executed from the shell.  All Delphix VDB hooks provide the environment variables ORACLE_HOME, ORACLE_SID, and ORACLE_BASE with appropriate values, but you may also want to set the PATH and LD_LIBRARY_PATH variables as well.  So, at the top of your hook script, you may want to include commands like...

    export PATH=${ORACLE_HOME}/bin:${PATH}
    export LD_LIBRARY_PATH=${ORACLE_HOME}/lib:${LD_LIBRARY_PATH}

    I also believe that a log file of the script should be created, so I create the name of that log file in a variable for later use...

    _logFile="/tmp/configure_clone_hook_'date '+%Y%m%d_%H%M%S''.log"

    This specifies that a log file will be created in the universal "/tmp" temporary file directory with the name "configure_clone_hook_YYMMDD_HHMISS.log, where "YYMMDD" is the date and "HHMISS" is the time the file was created.

    Then, when executing SQL*Plus, I personally like to first validate that the ORACLE_HOME directory exists, that the necessary subdirectories also exist, and of course that the Oracle executables exist and are executable...
    if [[ "${ORACLE_SID}" = "" ]]
    then
    echo "'date' - ERROR: ORACLE_SID variable not set; aborting..." | tee -a ${_logFile}
    exit 1
    fi
    if [[ "${ORACLE_HOME}" = "" ]]
    then
    echo "'date' - ERROR: ORACLE_HOME variable not set; aborting..."
    | tee -a ${_logFile} exit 1
    fi
    if [ ! -d ${ORACLE_HOME} ]
    then
    echo "'date' - ERROR: ORACLE_HOME directory \"${ORACLE_HOME}\" not found; aborting..." | tee -a ${_logFile}
    exit 1
    fi
    if [ ! -x ${ORACLE_HOME}/bin/sqlplus ]
    then
    echo "'date' - ERROR: executable \"${ORACLE_HOME}/bin/sqlplus\" not found; aborting..." | tee -a ${_logFile}
    exit 1
    fi
    Finally, once everything is ready, execute the SQL*Plus command-line utility, while entering the SQL*Plus and SQL commands through standard input redirection, saving all output to the log file...

    ${ORACLE_HOME}/bin/sqlplus / as sysdba << __EOF__ >> ${_logFile}
    whenever oserror exit failure rollback
    whenever sqlerror exit failure rollback
    set echo on feedback on timing on
    insert into table (col_1, col_2, col_3) values (1, 2, 3);
    exit success commit
    __EOF__
    if (( $? != 0 ))
    then
    echo "'date' - ERROR: SQL*Plus script failed; aborting..." | tee -a ${_logFile}
    exit 1
    fi
    The INSERT command is the fourth line in the code fragment above...

    Finally, if the hook is completing successfully, be sure to return the exit status of zero ("0") indicating successful completion back to Delphix, otherwise the hook will fail and (most likely) the entire operation (i.e. provision, refresh, etc) will also fail.  Only return a non-zero exit status back to Delphix if you wish the entire Delphix operation to fail.

    I will send additional examples running SQL*Plus as well as the Oracle DataPump Export and Import utilities.  These examples are intended for use in the Pre-Refresh and Post-Refresh hooks in order to preserve the settings of Oracle database account passwords and database link definitions across a REFRESH operation.  This resolves a problem where a REFRESH from the source completely replaces everything in a VDB with the values in the source database, which is often a production database.  It should only be necessary to reset Oracle database account passwords and database link definitions in a VDB once, when that VDB is initially provisioned.  But without these hooks in the Pre-Refresh and Post-Refresh hooks, passwords and dblinks would have to redefined after every refresh too.  The scripts are named "ora_vdb_prerefresh.sh" and "ora_vdb_postrefresh.sh".

    Please use these scripts as a template for other similar hook operations?

    Please let me know what you think?

    Thanks!

    -Tim


  • 5.  RE: Does replacing the physical databases with Virtual database,creates any issues in maintaining data bases for longer run
    Best Answer

    Posted 04-18-2019 03:18:00 PM
    Mahesh,

    Responding to your question about using VDBs for performance testing...

    If you are trying to improve the performance of specific programs during development or in unit-testing, VDBs are a great test bed because of your ability to refresh, rewind/restore, and otherwise manipulate the state of the VDB.

    However, if you are attempting to determine the overall performance of programs or applications in production environments, then you should test that performance using hardware which is similar to the production environment.  Virtual databases differ from "physical" databases in the way their storage (i.e. datafiles, redo (journal) files, and control files) is deployed, and it is certain that your production database is not a VDB, so performance testing for production on a system unlike production is not recommended.

    Hope this helps...

    -Tim


  • 6.  RE: Does replacing the physical databases with Virtual database,creates any issues in maintaining data bases for longer run

    Posted 04-18-2019 03:21:00 PM
    So sorry, this particular response was for another thread...


  • 7.  RE: Does replacing the physical databases with Virtual database,creates any issues in maintaining data bases for longer run

    Posted 04-18-2019 03:34:00 PM
    Tim, Thank you for your reply. I agree with your answer about unit testing. Regarding performance testing, what if I have baselines created with virtual vdb and then for new release with new code and new configuration I create another baseline and just compare the increase in response times. That could potentially tell me about any performance issues in overall application. I agree it will not give me true performance of production but difference in response times could tell me where the problem is? Please let me know if you disagree.


  • 8.  RE: Does replacing the physical databases with Virtual database,creates any issues in maintaining data bases for longer run

    Posted 04-18-2019 03:49:00 PM
    That could work, although such comparisons require great skill in writing queries.  Enjoy!


  • 9.  RE: Does replacing the physical databases with Virtual database,creates any issues in maintaining data bases for longer run