Openedge Database and Netapp storage to take and handle snapshots - Forum - OpenEdge RDBMS - Progress Community

Openedge Database and Netapp storage to take and handle snapshots


Openedge Database and Netapp storage to take and handle snapshots

This question is not answered

Hi all,

For the databases in Oracle and SQL we are looking to use snapshot technology in our development environments. What are we looking for? well... we are handling a DB form aprox 0.5 Tb and are running portfolio batch processes that are performing updates over a complete portfolio. In test cycles we want to test and compare these runs. For now we are working with Backup - restore, but this is a rather time consuming proces. Anyone any ideas - sugestions for us? does openedge support NetApp principles or does it handle it as a storage system like the rest.

Greetings, Benny

All Replies
  • proquiet dbname -C enable


    proquiet dbname -C disable

  • The "proquiet" command only queues up a request for a quiet point -- when it retruns you  cannot assume that the quiet point has taken effect.

    This can take some time and it occurs asynchrnously from the proquiet command.

    After the "proquiet" you need to monitor the .lg file and wait for a message that the quiet point has been enabled.

    Tom Bascom

  • OpenEdge and NetApp are not aware of each other. The OS is between them. OpenEdge just sees storage/filesystems presented by the OS.

    We are using this method daily, to create test environments (Linux).

    Requires some shell scripting effort, using NetApp Snapdrive commands.

    Snapshots will grow in size, depending on changes in source and target, using space on your source/production storage system - monitor capacity very carefully! You can also use "split" to create a full independent clone.

  • Ah ok, thanks, so this means Openedge just sees a file system and we can use the NetApp functionalities.  Do you hav some examples to give me an idea?


  • It is worth noting that you could also take your snap while the databases are down, instead of using proquiet.

    For reference below, "[NA:.......]"  means various NetApp snapdrive and OS shell commands in script(s).

    The entire process amounts to more than 1000 lines of scripts, and it takes about 40mins for around 800GB. The time it takes is not closely tied to the data size though, but more proportional to the number of filesystems etc.

    The OpenEdge related parts of the process are below.


    On the SOURCE:

    proquiet enable (and wait for confirm)

    [NA: snap here]

    Snap all filesystems which any database file is on.

    Note on Temporary Directory (-T):

    if you do not include these in the snap, the directories need to be re-created manually on the target

    if you do include these in the snap, they should be emptied on the target

    proquiet disable (and confirm)

    On the TARGET

    (the target could be a different system, or somewhere else on the same system)

    (Final backup of what you are about to delete - your choice!)

    Shutdown the target databases

    Remove the target databases

    [NA: Remove all target filesystems, filesystem mount points, logical volumes, volume groups, LUNs etc]

    [NA: Optional, delete old snap that you are no longer using]

    [NA: Connect to the latest snap]

    There will be files in place which belong to the source running instances - these need to be removed

    If your database paths have changed from the source, you will need to:

    Replace the file (from the source) with another one with the correct details

    Run prostrct repair

    Clear out / create -T directories

    Start databases.


    Your starting point will be to get your NetApp resource to install Snapdrive, then begin managing your filesystems for OpenEdge from the OS.

    For details on NetApp requirements, you will be much better served on the NetApp websites and forums.

  • > On Mar 3, 2017, at 4:55 AM, Benny Van Meersche wrote:


    > so this means Openedge just sees a file system and we can use the NetApp functionalities

    not so fast.

    it means we see an ordinary filesystem (posix api on linux, something else on windows) and have no idea what netapp is doing under the covers.

    that does NOT mean that all netapp functionality will work. progress has not tested these things. some things probably will not work and the ones that do work sometimes require special procedures, such as setting a quiet point.

    there is no guarantee from progress beyond the ordinary i/o operations. if you encounter netapp functionality that does not work, you will not get much help from progress other than tech support doing the best they can.