Hi Mark, hi John,
yes, as a rule you should avoid using param_addvolume, because
this command will change the configuration file ONLY! NO action
takes place in the db kernel! The correct way to add a volume
is the db_addvolume command. This will change the configuration file
and additional the db kernel will be informed about the new volume.
You can see the db_addvolume(obsolete db_adddevice) in the dbm.prt
file and the corresponding kernel command "ADD DATA VOLUME ..." in
the dbm.utl file!
Note that each volume has a magic header page called IOMan_InfoPage.
This page contains among other informations the logical predecessor
and successor of a volume. If you change the configuration by hand
without informing the kernel about the new volume, the next restart
will fail!
Sometimes in the past we had problems if the configuration file (often
called param file) was CHANGED and somebody wants to add a data volume,
because the database could not start caused by a db full situation.
In this situation the db_addvolume command fails with something like:
"param file is dirty - add volume not possible;
first bring database in state online then add the new data volume"
But this isn't possible if the restart fails with db full! So we have
a workaround:
- do not use db_addvolume! (break the general rule)
- bring the database in state offline
- add the new volume with param_addvolume to the configuration
- bring the database in state admin
- send the command util_execute ADD DATAVOLUME 'volumeName' PAGES <pageCount>
DEVICE <logicalVolumeNumberWithinConfigurationFile>
- restart database
This workaround is obsolete with the new releases. See the following
bug reports:
http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=1&ErrorID=1128555
http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=1&ErrorID=1128553
http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=1&ErrorID=1128552
I hope this clarifies the joyless "add data volume - db full - restart"
situation.
BTW:
If the log area is your problem you should use the autosave log feature.
You should be VERY careful with the "SET LOG AUTO OVERWRITE ON" because
this interruptes your log backup history!!!
Regards,
Torsten
SAP DB, SAP Labs Berlin
-----Original Message-----
From: John L. Singleton [mailto:[EMAIL PROTECTED]
Sent: Freitag, 16. April 2004 04:44
To: Mark Johnson
Cc: Maxdb List
Subject: Re: Adding Dev Space after Database Full
Mark,
Try the command, db_addvolume. As a general rule, you should avoid
useing param_addvolume after you install the instance. Use
param_addvolume to add a mirrored log volume, for example, but not a
data volume.
For example: (in admin operational state)
#dbmcli -d <dbname> -u <dbmuser,dbmpass>
#db_addvolume DATA DAT_000X F <size in pages>
By default, when your logs become full, you must back them up. This will
"clean" the transaction log as you say.
You might consider setting your database logs to "Auto Overwrite" ---
this will make it impossible for the log to overflow.
Do this with the command: (in dbmcli)
#dbmcli -d <dbname> -u <dbmuser,dbmpass>
# db_admin
# util_connect
# util_execute SET LOG AUTO OVERWRITE ON
# util_release
Hope this helps,
JLS
Mark Johnson wrote:
> I have had this problem before and received a few suggestions, but
> have not solved this problem yet. Our database fills and, in
> addition, there are many transactions in the transaction log. This
> prevents the database from comming up into warm mode (it halts while
> moving transactions to from the transaction log to the database I think).
>
> I can get the database to admin mode, but the utilities will not allow
> me to add a dev space while the database is in admin mode. So, I
> either need a way to add a dev space in admin (or cold mode), or be
> able to flush the transaction log and make all the records in the
> database appear "clean" again.
>
> Thanks in advance for any help.
> Mark
>
>
>
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
