Fragmented dbspaces 
Author Message
 Fragmented dbspaces

Yup, dbspaces *not* fragmented tables.
Our system holds about 75Gb on a mixture of 4.3Gb & 9Gb disks, raw
chunks, HP-UX 10.20, IDS7.31.
When it was built we ran some predictions re. growth and so on based on
the figures given to us by the business analysis group, upon which we
based our data distribution strategy; the upshot being that we settled
on a dozen or so dbspaces, some holding tables that were fragmented by
example.
Anyway, over the last three years the data has grown at a different
rate from that envisaged, and we have had to extend some dbspaces by
adding new chunks when necessary.
Unfortunately, due to financial restrictions and a blinkered IT
management structure, the extra chunks added to some of the dbspaces
has meant that some have got several chunks on several disks. So a 15Gb
space may have a 10Gb initial chunk and 5 1Gb chunks, all on separate
disks. This is obviously not optimal.
We are just about to move disk technology and therefore shortly we are
to move the data from the old disks to the new.
The business cannot cope with a protracted downtime (24 hours max), so
we HAVE to accomplish this by using a Level-0 archive from the old
system and restore this (using ontape) to the new system.
In order for ontape archive/restore to work, the target structure has
to be identical.
What I'd like is to consolidate the dbspaces chunks into a single chunk
per dbspace.
Any clues as to how we can do this - I've got a feeling someone will
say 'use HPL to export all the tables, build a new instance and reload
the tables'. That will take about 5 days, so not an option. Can we
restore our L0 ontape to a structure with the same dbspaces (with the
same total sizes) but only one chunk each?

Probably not.

Malc

Sent via Deja.com http://www.***.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT
 Fragmented dbspaces

See below . . . .

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

Sent: Wednesday, December 06, 2000 6:49 AM

Subject: Fragmented dbspaces

Yup, dbspaces *not* fragmented tables.
Our system holds about 75Gb on a mixture of 4.3Gb & 9Gb disks, raw
chunks, HP-UX 10.20, IDS7.31.

JC>   Somehow, I don't feel so bad now . . . .

When it was built we ran some predictions re. growth and so on based on
the figures given to us by the business analysis group, upon which we
based our data distribution strategy; the upshot being that we settled
on a dozen or so dbspaces, some holding tables that were fragmented by
example.
Anyway, over the last three years the data has grown at a different
rate from that envisaged, and we have had to extend some dbspaces by
adding new chunks when necessary.
Unfortunately, due to financial restrictions and a blinkered IT
management structure, the extra chunks added to some of the dbspaces
has meant that some have got several chunks on several disks. So a 15Gb
space may have a 10Gb initial chunk and 5 1Gb chunks, all on separate
disks. This is obviously not optimal.
We are just about to move disk technology and therefore shortly we are
to move the data from the old disks to the new.

JC>  Same here, but we're changing OS levels . . .  so no backup and restore
here . . . .

The business cannot cope with a protracted downtime (24 hours max), so
we HAVE to accomplish this by using a Level-0 archive from the old
system and restore this (using ontape) to the new system.
In order for ontape archive/restore to work, the target structure has
to be identical.

JC>  That's right, the logical structure needs to be the same.  I am able to
take a level 0 archive from my production system and restore it to test
(using ontape).  Takes about 5 hours or so.  I have the same logical setup
(at the rawspace level), but not the same setup at the physical disk level.

What I'd like is to consolidate the dbspaces chunks into a single chunk
per dbspace.

JC>  Now that's different.  To my knowledge, there's no way to change the
logical setup of the dbspaces (dbspace consolidation) unless you export /
import.  Any way to do this on an ongoing basis (as part of admin) after the
fact?  Depending on your disk setup, you could possibly run reorgs over the
next 'x' week(end)s in order to consolidate.  That was our game plan once we
started talking about mirroring on our systems.  With just the underlying
disks changing, we planned to take a level 0 before and restore after.  Then
I'd take the next few weeks to monitor and reorg as necessary.

Any clues as to how we can do this - I've got a feeling someone will
say 'use HPL to export all the tables, build a new instance and reload
the tables'. That will take about 5 days, so not an option. Can we
restore our L0 ontape to a structure with the same dbspaces (with the
same total sizes) but only one chunk each?

JC>  Sorry, restoring a tape and changing the logical dbspace structure in
one step is not possible.  I'll be going through something similar in a few
weeks, where I need a fast way to move data between boxes w/o using HPL in
express mode (upgrading from HPUX 10.20 to HPUX 11.0).  I'm planning to try
out HPL and pipes OR Art Kagel's dbcopy.

Probably not.

Malc

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT
 
 [ 2 post ] 

 Relevant Pages 

1. Index space allocation in fragmented dbspaces

2. detecting fragmented dbspace...

3. dbspace of non-fragmented tables

4. Fragment by Expression, Remainder dbspace

5. To fragment or not to fragment - opinions requested (fwd)

6. To fragment or not to fragment - opinion

7. To fragment or not to fragment - opinions requested

8. ontape -r -D dbspace leaves inconsistent dbspace/chunk...

9. ontape -r -D dbspace leaves inconsistent dbspace/chunk...

10. alter fragment on table <table name> init in <dbspace>

11. How to de-fragment the database


 
Powered by phpBB® Forum Software