Moving a database to new disk array 
Author Message
 Moving a database to new disk array

We have a database running under 7.22. The chunks have become
"fragmented" (spread across several volume groups under HPUX) and that
limits our flexibility wrt how we can effectively use those volume
groups ... we have a lot of 2G logical volumes that are too small to be
of much value for anything else. So they sit fallow.

I would like to clean this up by moving the database to its own new
volume group on another disk array. This would eliminate the
"fragmentation" and allow me to reconfigure the old space so it is more
useful for other purposes.

What is the best way to do this? From what I gather from my reading of
ontape, the chunk paths are stored as part of the ontape backup, which
means I can only restore to the same chunks, so that's out. On the
other hand, dbexport/dbimport seem seem to hold some promise ... is
this the way to go? Are there other better options I should be
considering?



Thu, 03 Jun 2004 21:55:25 GMT
 Moving a database to new disk array

You can use ontape to restore. What ontape needs is the same name, path and
size of the chunks (original). You need to create a soft link with the same
path, name. Soft link can point to any disk anywhere in the system). Niraj

Quote:
-----Original Message-----


Sent: Sunday, December 16, 2001 8:55 AM

Subject: Moving a database to new disk array

We have a database running under 7.22. The chunks have become
"fragmented" (spread across several volume groups under HPUX) and that
limits our flexibility wrt how we can effectively use those volume
groups ... we have a lot of 2G logical volumes that are too small to be
of much value for anything else. So they sit fallow.

I would like to clean this up by moving the database to its own new
volume group on another disk array. This would eliminate the
"fragmentation" and allow me to reconfigure the old space so it is more
useful for other purposes.

What is the best way to do this? From what I gather from my reading of
ontape, the chunk paths are stored as part of the ontape backup, which
means I can only restore to the same chunks, so that's out. On the
other hand, dbexport/dbimport seem seem to hold some promise ... is
this the way to go? Are there other better options I should be
considering?



Thu, 03 Jun 2004 23:32:04 GMT
 Moving a database to new disk array


Quote:
>We have a database running under 7.22. The chunks have become
>"fragmented" (spread across several volume groups under HPUX) and that
>limits our flexibility wrt how we can effectively use those volume
>groups ... we have a lot of 2G logical volumes that are too small to be
>of much value for anything else. So they sit fallow.

>I would like to clean this up by moving the database to its own new
>volume group on another disk array. This would eliminate the
>"fragmentation" and allow me to reconfigure the old space so it is more
>useful for other purposes.

>What is the best way to do this? From what I gather from my reading of
>ontape, the chunk paths are stored as part of the ontape backup, which
>means I can only restore to the same chunks, so that's out. On the
>other hand, dbexport/dbimport seem seem to hold some promise ... is
>this the way to go? Are there other better options I should be
>considering?

You can only restore from a backup if the machine you are restoring to
has the same logical names for bits of disk space which are each at
least as large as the ones on the source machine so if you are wanting
to change the logical names it's no use.  If you are wanting to rejuggle
the physical disk behind the logical names them it's OK and much faster
than export/import.

If you have to export/import it takes a lot longer, but you get the
chance to edit the .sql file created as part of the process to determine
which bit of disk each table goes into.  Of course you would have had to
set up the logical names for bits of disk, and create the instance of
Online first and then create the dbspaces required.

--
Five Cats



Thu, 03 Jun 2004 23:43:45 GMT
 Moving a database to new disk array

I would take the big tables, unload them (to pipe) reload them (via pipe) to
the new spaces.  Once you've got all of the big guys dealt with, then do a
dbexport and pick up the rest.

cheers
j.

Quote:
----- Original Message -----


Sent: Sunday, December 16, 2001 8:55 AM
Subject: Moving a database to new disk array

> We have a database running under 7.22. The chunks have become
> "fragmented" (spread across several volume groups under HPUX) and that
> limits our flexibility wrt how we can effectively use those volume
> groups ... we have a lot of 2G logical volumes that are too small to be
> of much value for anything else. So they sit fallow.

> I would like to clean this up by moving the database to its own new
> volume group on another disk array. This would eliminate the
> "fragmentation" and allow me to reconfigure the old space so it is more
> useful for other purposes.

> What is the best way to do this? From what I gather from my reading of
> ontape, the chunk paths are stored as part of the ontape backup, which
> means I can only restore to the same chunks, so that's out. On the
> other hand, dbexport/dbimport seem seem to hold some promise ... is
> this the way to go? Are there other better options I should be
> considering?



Fri, 04 Jun 2004 02:57:37 GMT
 Moving a database to new disk array
My understanding of the original question was that he wanted to re-configure
the tables within the chunks.  If so, I think the suggestion below is wrong,
since it will preserve the original layout.

In order to re-organise the chunks, you need to unload/reload the data, ot
otherwise move it.  The fact that you have a " lot of 2G logical volumes"
suggests that dbexport/dbimport may be too slow, as it is an ASCII unload
method, and in particualr the index re-builds can take a very long time.

From the textbook, onunload/onload would be the way to go.  But it's very
flaky and consistently has one or other bug in each successive release that
renders it useless.  If you have a small-ish number of tables, then ALTER
FRAGMENT ... INIT IN is an efficient method of moving tables between
dbspaces.  Alternatives are High performance Loader, or a simple SQL
unload/load.

If you have a lot of tables it's going to very tedious, so give
onunload/onload a try.


Quote:

> You can use ontape to restore. What ontape needs is the same name, path
and
> size of the chunks (original). You need to create a soft link with the
same
> path, name. Soft link can point to any disk anywhere in the system). Niraj



Fri, 04 Jun 2004 05:39:46 GMT
 Moving a database to new disk array
Which leads to an enhancement request that I've always wanted:

Add a parameter to dbexport whereby you can exclude specified tables
from the export...

Allen

Quote:

> I would take the big tables, unload them (to pipe) reload them (via pipe) to
> the new spaces.  Once you've got all of the big guys dealt with, then do a
> dbexport and pick up the rest.

> cheers
> j.

> ----- Original Message -----


> Sent: Sunday, December 16, 2001 8:55 AM
> Subject: Moving a database to new disk array

> > We have a database running under 7.22. The chunks have become
> > "fragmented" (spread across several volume groups under HPUX) and that
> > limits our flexibility wrt how we can effectively use those volume
> > groups ... we have a lot of 2G logical volumes that are too small to be
> > of much value for anything else. So they sit fallow.

> > I would like to clean this up by moving the database to its own new
> > volume group on another disk array. This would eliminate the
> > "fragmentation" and allow me to reconfigure the old space so it is more
> > useful for other purposes.

> > What is the best way to do this? From what I gather from my reading of
> > ontape, the chunk paths are stored as part of the ontape backup, which
> > means I can only restore to the same chunks, so that's out. On the
> > other hand, dbexport/dbimport seem seem to hold some promise ... is
> > this the way to go? Are there other better options I should be
> > considering?



Sat, 05 Jun 2004 00:50:15 GMT
 Moving a database to new disk array

Quote:

> We have a database running under 7.22. The chunks have become
> "fragmented" (spread across several volume groups under HPUX) and that
> limits our flexibility wrt how we can effectively use those volume
> groups ... we have a lot of 2G logical volumes that are too small to be
> of much value for anything else. So they sit fallow.

> I would like to clean this up by moving the database to its own new
> volume group on another disk array. This would eliminate the
> "fragmentation" and allow me to reconfigure the old space so it is more
> useful for other purposes.

> What is the best way to do this? From what I gather from my reading of
> ontape, the chunk paths are stored as part of the ontape backup, which
> means I can only restore to the same chunks, so that's out. On the
> other hand, dbexport/dbimport seem seem to hold some promise ... is
> this the way to go? Are there other better options I should be
> considering?

You CAN use ontape to do this as long as either:
1) You used links as your chunk pathnames originally and not physical

device paths -or-
2) You can dstroy the original devices and either replace them with the

new structure or replace the paths with links to the new structure if you

DID us physical device names.

You should ALWAYS use links for chunk paths so that you have the

flexibility to reorganize your disk structures as needed just be pointing
the links to new devices and restoring the server or copying
the data from the original devices while the engine is
offline.

Art S. Kagel

Art S. Kagel



Sat, 05 Jun 2004 07:19:36 GMT
 Moving a database to new disk array

Errr, I neglected to mention that to dbexport only the small tables (after
you've done the larger tables), you will have to drop those larger tables so
they don't get exported.

cheers
j.

Quote:
----- Original Message -----


Sent: Monday, December 17, 2001 11:50 AM
Subject: Re: Moving a database to new disk array

> Which leads to an enhancement request that I've always wanted:

> Add a parameter to dbexport whereby you can exclude specified tables
> from the export...

> Allen


> > I would take the big tables, unload them (to pipe) reload them (via
pipe) to
> > the new spaces.  Once you've got all of the big guys dealt with, then do
a
> > dbexport and pick up the rest.

> > cheers
> > j.

> > ----- Original Message -----


> > Sent: Sunday, December 16, 2001 8:55 AM
> > Subject: Moving a database to new disk array

> > > We have a database running under 7.22. The chunks have become
> > > "fragmented" (spread across several volume groups under HPUX) and that
> > > limits our flexibility wrt how we can effectively use those volume
> > > groups ... we have a lot of 2G logical volumes that are too small to
be
> > > of much value for anything else. So they sit fallow.

> > > I would like to clean this up by moving the database to its own new
> > > volume group on another disk array. This would eliminate the
> > > "fragmentation" and allow me to reconfigure the old space so it is
more
> > > useful for other purposes.

> > > What is the best way to do this? From what I gather from my reading of
> > > ontape, the chunk paths are stored as part of the ontape backup, which
> > > means I can only restore to the same chunks, so that's out. On the
> > > other hand, dbexport/dbimport seem seem to hold some promise ... is
> > > this the way to go? Are there other better options I should be
> > > considering?



Sat, 05 Jun 2004 20:34:30 GMT
 
 [ 8 post ] 

 Relevant Pages 

1. Move System Database to New Disk

2. Moving database to new disk

3. Moving SQL7 Cluster to a new array

4. Moving data to a new array...

5. Moving Tempdb to a new disk

6. moving databse to new disks

7. How to moving DB to new disks/controller

8. Disk Array v/s hard Disk

9. move INTERBASE ARRAY to DELPHI ARRAY ?

10. Disk to Disk move of DB2 DB

11. Moving a database to a different disk


 
Powered by phpBB® Forum Software