Openedge Database and Netapp storage to take and handle snap

Posted by Benny Van Meersche on 28-Feb-2017 01:53

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

Posted by cjbrandt on 28-Feb-2017 06:54

proquiet dbname -C enable

snapshot

proquiet dbname -C disable

Posted by ChUIMonster on 28-Feb-2017 08:13

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.

Posted by Rohan on 28-Feb-2017 12:21

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.

Posted by Benny Van Meersche on 03-Mar-2017 03:54

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?

Benny

Posted by Rohan on 03-Mar-2017 06:07

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 db.lk 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 db.st 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.

Posted by gus bjorklund on 04-Mar-2017 11:10

> 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.

This thread is closed