Any other way to redefine a database device without dumping all databases and reloading?

Any other way to redefine a database device without dumping all databases and reloading?

Post by Bobbi Stewar » Fri, 07 Feb 1997 04:00:00



When we created our database device (dd1), we created it smaller than the
logical volume it resides on and so it is not taking full advantage of the
space on the volume.  We can no longer increase the size of our database on
this device either.  We've been told by consultants that the solution is to
drop our database, redefine the device, and then reload the database.  We
don't want to do this because it may involve reloading system databases as
well where we would encounter numerous problems.

Another option we have discovered is that we do have space available on two
other volumes and we're thinking we may be able to just extend our database
device onto these other volumes, not having to do any kind of dump/restore.
 But this sounds almost too easy.  

Any other suggestions or advice on the options above?

Bobbi

 
 
 

Any other way to redefine a database device without dumping all databases and reloading?

Post by Bret Halfo » Sat, 08 Feb 1997 04:00:00



|> When we created our database device (dd1), we created it smaller than the
|> logical volume it resides on and so it is not taking full advantage of the
|> space on the volume.  We can no longer increase the size of our database on
|> this device either.  We've been told by consultants that the solution is to
|> drop our database, redefine the device, and then reload the database.  We
|> don't want to do this because it may involve reloading system databases as
|> well where we would encounter numerous problems.

I would agree with the consultants.  Why on earth would this involve reloading
the system databases? (unless you have your user database on the master device,
which is poor practice in the first place.  If that is the case, let me know).

It is presumably possible to directly update the sysdevices.high field to
enlarge the device to the real size of the volume, but I don't advise doing
it and Sybase does not support doing so.  If you miscalculate, you will be

Quote:>very< unhappy at some unpredictable* time in the future.

* Actually, Murphy [et al] claims to have an algorithm that will predict this.
For explicit details, see:
  http://www.ug.cs.sunysb.edu/~nadlerj/murphy/murphy_laws.html
  http://www.ug.cs.sunysb.edu/~nadlerj/murphy/technology.html

|> Another option we have discovered is that we do have space available on two
|> other volumes and we're thinking we may be able to just extend our database
|> device onto these other volumes, not having to do any kind of dump/restore.
|>  But this sounds almost too easy.  

You can't extend your >device< onto other volumes, but you could certainly run
disk init to create a new sybase device on those volumes and then alter your

Quote:>database< onto the new device.  You will still be wasting the unused disk

space on the original volume, but will have more room in your database for
future growth.

--
---------------------------------------------------------------------
| Bret Halford                    Imagine my disappointment       __|
| Sybase Technical Support        in learning the true nature  __|  
| 6400 S. Fiddlers Green Circle   of rec.humor.oracle...    __|  
| Englewood, CO 80111-4954 USA                             |
============================================================

 
 
 

Any other way to redefine a database device without dumping all databases and reloading?

Post by Manoj Same » Tue, 11 Feb 1997 04:00:00



> When we created our database device (dd1), we created it smaller than the
> logical volume it resides on and so it is not taking full advantage of the
> space on the volume.  We can no longer increase the size of our database on
> this device either.  We've been told by consultants that the solution is to
> drop our database, redefine the device, and then reload the database.  We
> don't want to do this because it may involve reloading system databases as
> well where we would encounter numerous problems.

> Another option we have discovered is that we do have space available on two
> other volumes and we're thinking we may be able to just extend our database
> device onto these other volumes, not having to do any kind of dump/restore.
>  But this sounds almost too easy.

> Any other suggestions or advice on the options above?

> Bobbi

You can create additional devices on the free space using
"disk init" and then extend your database to those using
alter database

HTH

Manoj

 
 
 

1. named, reload database?

According to the man pages for named, 'kill -2 named_pid' dumps its
database. I'm running 3.4-RELEASE and named behaves as advertised
dumping /etc/namedb/named_dump.db. But, 'kill -1 named_pid' doesn't
load the database, contrary to the man pages. Does anyone know
how to make named load the database?

Ian Stirling

2. Netscape 4 problems

3. State Database and State Database Replicas problem?

4. LPR:Who are you - error

5. About dynamic memory database or real-time database

6. RH 5.1 boot: modprobe not an ELF file -> eth0 init fails

7. How to convert flat file database to dbm databases

8. Timmer function

9. How can I synchronize the database between two MySQL database server

10. Gnu database database manager (gdbm)

11. Dumping multiple databases to ONE tape

12. Dumping Large Database to big AIX file

13. DHCP database dump tool for AIX 4.2