resize the disk space

[megat razizul]

We have critical disk space on DSA9 and only leave 3.99GB. On DSA9 contain Database and its our production and can’t be shutdown. We still have 139.99GB on the eva 5000 Storage works.

Thus, please advise us for below:

1. If we mount the available space either to Prod1 or Prod2..... then what is the impact. Does it require shutdown? or
2. Can we mount it as new volume name as Prod3 and then assigned the databse to the new volume and again what is the impact

We using VMS 7.3-2


DSA9: Mounted 0 PROD01 3.99GB 4289 2
DSA10: Mounted 0 PROD02 45.90GB 3117 2

[Wim Van den Wyngaert]

Which database ?

Normally you have to shut the applic and db, copy the data to the new disk, change db config/logicals, restart db and restart applic.

Wim

[Robert Gezelter]

megat,

Two solutions come to mind, some research will be needed to determine the precise details of what the correct path is.

One solution is to enable dynamic volume expansion on DSA9. This would allow one to transition DSA9 to larger size containers on the EVA without interrupting production. The combination of expandable volumes and host-based shadowing is particularly powerful, as I have presented in "Migrating OpenVMS Storage Environments without Interruption or Disruption" at HP Enterprise Technology Fora in the past (most recent session notes at http://www.rlgsc.com/hptechnologyforum/2007/1512.html ). This is supported under 7.3-2.

Another approach, less commonly used these days but still quite usable is volume sets. It is possible to add volumes to a volume set with little or no interruption in production. The volume set can also be managed as a single, albeit large, single entity. Care is required to ensure that all procedures are compatible, but I have used these successfully over the years.

Whichever approach is decided upon, please be careful to create a "toy" scenario on a test system, or at least a set of test volumes, to practice and test the transition. These do not generally have to be the size of the real system, but the various components must be there. When I demonstrated disk expansion using dynamic volume expansion and host-based shadowing, my demonstration used 10,000, 20,000, and 30,000 block files; large enough to demonstrate the concept, small enough to shadow copy in a reasonable time.

If this is truly a "time critical" environment, I do recommend commensurate care and caution. It may also be wise to retain experienced outside assistance to ensure a trouble-free outcome [Disclosure: I provide such services, as do several other regular contributors to this forum].

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Megat,

In the case of the dynamically expanding volume, the database need not even be stopped. No logical names are changed, the volume magically gets bigger from one instant to the next.

Properly done, the same is true of a bound volume set. The logical name points to the first volume in the set, and files (and extensions of files) go on the second volume if there is no space on the member that they are initially allocated on.

As always, the details are very important.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

Chances are excellent here that you'll have to stop the database at least briefly, and restart -- this presumes the disk has not already been set up for dynamic volume expansion (DVE).

If DVE is not already enabled, you'll have to mount the volume privately to enable it. (That you're asking the question implies DVE isn't enabled.) Which means you'll have a brief outage.

In the interim, start cleaning out the database to free up some disk space. Where data can be deleted, of course.

You'll need to identify whether DVE is enabled (post the output of SHOW DEVICE DSA9: /FULL if you're not sure) and you'll need to identify the particular database software involved.

Depending on the database software, it might be possible to migrate storage areas across spindles and this might be feasible on-line. This is a database question, and central to this question is the identity of the database software and its particular capabilities.

Further, some idea of the current configuration of the database can be required. Rdb, for instance, can have its root database located on one spindle, and various data areas on other spindles.

There are 140 gigabytes free in aggregate? The digital video recorder (DVR) I just installed for a customer had two terabytes of storage associated with it. That's basically a television with two terabytes. I'd accordingly suggest a reevaluation of production uptime requirements and the available hardware resources. Also a look at the plans for storage and hardware expansion, as the increases in storage requirements can sometimes be predictable for some applications; history can sometimes be predictive, and can help line up hardware expansions with scheduled outages.

[Hein van den Heuvel]

You mention "Database", but no details. What database?

Any database worth its name & price will allow for transparent additional storage area.
For example in Oracle one can just add a datafile to a tablespace.

So just create a fresh volume and expand the database onto that?! What is so hard about that?

fwiw,
Hein.

[megat razizul]

We using the prod1 and prod2 for locate tablespace and datafile only. So I assume go to the second choice where we create new volume and name it prod3 as your advice. Thanks

[Robert Gezelter]

Megat,

I do not understand the last posting in this thread.

1) Which database (and what version) is running?

2) If one is creating an additional volume, I would strongly recommend initializing is with Dynamic Volume Expansion. While one may opt not to expand the volume, it is far better to preserve that choice before the volume becomes a production volume. This will preserve the option of expanding the volume without interruption as described in my technical forum presentation that was referenced earlier in this thread.

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

To all (and the moderators),

There is a typographical error in my posting from earlier today.

"initializing is with Dynamic Volume Expansion." should read "initializing it with Dynamic Volume Expansion."

My apologies for any confusion or inconvenience.

- Bob Gezelter, http://www.rlgsc.com