Adabas D: Logfile full Problem
Heiko Stoermer
I created a new db in Adabas D 10 (Linux) and tried to insert about
60000 rows into a table. About halfway Adabas reported that the logfile
was full and that no more rows could be inserted. (The data dev was NOT
full, just the log).
I restarted the db, and now control says that the db is read-only.
(Can't I tell Adabas, that I dont want to care about the logfile? I
mean, there is no way for me to tell how big the log is going to be...
I actually don't even need the rollback mechanisms.)
The questions:
How do I get my db running again?
Is there a way to tell Adabas to take care of that logging stuff itself?
Can I disable logging, in the worst case?
Many questions, no answers.
(For now, I hope)
:-)
Heiko
--
-------------------------------------------------------------
Heiko Stoermer mailto:Heiko.S...@Exklusiv.DE
K&K Kommunikationssysteme Tel.: 0821/ 2589220
Haunstetterstr. 19 Fax: 0821/ 2589222
86161 Augsburg WWW: http://www.exklusiv.de
Armin Hassenpflug
start xcontrol and backup your log (BACKUP/SAVE/LOG ); then restart your
db.
>
> Is there a way to tell Adabas to take care of that logging stuff itself?
you can start "Autosave Log" (menu OPTIONS /AUTOSAVE LOG) or change the log
mode to DEMO
Marian Eichholz
>> How do I get my db running again?
>
>start xcontrol and backup your log (BACKUP/SAVE/LOG ); then restart your
>db.
If it is _really_ full, that is not enough, for it won't save. It
happened to me some time ago. At last I managed it to RESTORE/CLEAR
LOG, and I could restart warm.
>> Is there a way to tell Adabas to take care of that logging stuff itself?
>
>you can start "Autosave Log" (menu OPTIONS /AUTOSAVE LOG) or change the log
>mode to DEMO
Well, but the log must me large enough to get all transactions between
start and COMMIT. So one has to break up the transactions into smaller
pieces and commit them separately to keep the log small.
With kind regards,
Marian Eichholz
- ----------------------------------------------------------
Disclaimer: All opinions and statements in this article are my own.
They are not necessarily related to those of my employer unless
otherwise stated.
- ----------------------------------------------------------
Dunkelberg & Stute Dipl.-Ing. Marian M. Eichholz
patent attourneys dus...@ibm.net
>To reply via email, remove the <removeme>-Tag from the address.<
Adabas D Support
Heiko Stoermer schrieb:
>
> Hi,
> I created a new db in Adabas D 10 (Linux) and tried to insert about
> 60000 rows into a table. About halfway Adabas reported that the logfile
> was full and that no more rows could be inserted. (The data dev was NOT
> full, just the log).
> I restarted the db, and now control says that the db is read-only.
See the Control manual about log modes, handling, "log full" etc.
In your case, you have to do a SAVE LOG to get space there.
>
> (Can't I tell Adabas, that I dont want to care about the logfile? I
> mean, there is no way for me to tell how big the log is going to be...
> I actually don't even need the rollback mechanisms.)
NO - Adabas D is a true DBMS, it follows the "atom" principle of
transactions, so it needs a log.
As a rough estimate of log information generated by your applications,
add the sizes of all rows inserted, all rows deleted, and twice all
rows updated.
Even if you claim you could do without "rollback", the database can
not. What do you expect to happen when you modify lots of data
without committing, and then power fails ? Adabas D will implicitly
do a rollback of that transaction when restarting (into "warm" mode).
>
> The questions:
> How do I get my db running again?
Control -> Backup/Restore -> Save log
Control -> Operation -> Restart -> Warm
> Is there a way to tell Adabas to take care of that logging stuff itself?
You need not tell Adabas D to do logging - it will do so by itself.
You can tell Adabas D to take care of saving the log automatically
("AUTOSAVE LOG"), that will prevent a "log full" situation
(assuming your transactions are short enough, by COMMIT or ROLLBACK,
so that they do not exceed the log segment size).
See the Control manual.
However by your text I guess that you do not want to assign disk
space or a tape drive for automatic log saves.
>
> Can I disable logging, in the worst case?
No.
The closest approximation is to use "DEMO" mode for logging.
Again, see the manual.
Anybody using "DEMO" log please bear in mind that the name has a
meaning: There is _absolutely_no_way_ to recover from disk failures
because you can not SAVE a DELO log. It is for testing and playing
around in cases where your data do not matter (= either have no
value for you or can be reconstructed from sources external to the
database).
>
> Many questions, no answers.
Did you read the manual ?
> (For now, I hope)
> :-)
>
> Heiko
>
> --
> -------------------------------------------------------------
> Heiko Stoermer mailto:Heiko.S...@Exklusiv.DE
> K&K Kommunikationssysteme Tel.: 0821/ 2589220
> Haunstetterstr. 19 Fax: 0821/ 2589222
> 86161 Augsburg WWW: http://www.exklusiv.de
With kind regards
Joerg Bruehe
--
SQL Datenbanksysteme GmbH
- Adabas D Support - http://www.adabas.com
Alt-Moabit 96 news:comp.databases.adabas
D 10559 Berlin mailto:xsq...@sql.de
Germany
Heiko Stoermer
> You can tell Adabas D to take care of saving the log automatically
> ("AUTOSAVE LOG"), that will prevent a "log full" situation
> (assuming your transactions are short enough, by COMMIT or ROLLBACK,
> so that they do not exceed the log segment size).
Does this mean that if I load 60000 rows from some sql-dumpfile with xload I
would have to insert extra "commit" statements after, say, every 1000 rows to
prevent exceeding the log segment size?
>
> See the Control manual.
> However by your text I guess that you do not want to assign disk
> space or a tape drive for automatic log saves.
Well, dont laugh, but I really dont need these log saves. I managed to save
them to /dev/null.
But if I think about that now: if the db wants to restore from these saved
logs, it will fail terribly while reading from /dev/null. I will have to
correct this situation.
> Did you read the manual ?
Oh man, we really needed quick decisions!
;-)
Not being an experienced Oracle, Adabas or Informix Admin, it took me a week
to get our existing db running with adabas anyway...
This is a lot more complex than that mysql-toy we use.
But thanks a lot, you really helped me. You obviously know what you are
talking about...
Regards,
Heiko.
Marian Eichholz
>> See the Control manual.
>> However by your text I guess that you do not want to assign disk
>> space or a tape drive for automatic log saves.
>
>Well, dont laugh, but I really dont need these log saves. I managed to save
>them to /dev/null.
The straighter way is DEMO mode.It cycles the Log.
>But if I think about that now: if the db wants to restore from these saved
>logs, it will fail terribly while reading from /dev/null. I will have to
>correct this situation.
No, the automatic saves are only explicitly used by the admin on
RESTOREing LOG. The automatical use of Logs for rolling back
transactions is the reason for the transaction log itself.
Therefore You cannot use /dev/null as log devspace, but as path for
autosave log.
>This is a lot more complex than that mysql-toy we use.
Adabas is a true RDBMS with full transaction support. MySQL lacks
these essential features for speed issues.
Adabas D Support
Heiko Stoermer schrieb:
>
> Adabas D Support wrote:
>
> > ((...))
> > (assuming your transactions are short enough, by COMMIT or ROLLBACK,
> > so that they do not exceed the log segment size).
>
> Does this mean that if I load 60000 rows from some sql-dumpfile with
> xload I
> would have to insert extra "commit" statements after, say, every 1000
> rows to
> prevent exceeding the log segment size?
Not with Load, if you use the default settings - because Load
has an "Autocommit" feature which lets Load insert these COMMITs
automatically.
You can use the SET command to switch that off (risking the
overflow ...) or to change the number of rows per transaction,
the default is 100 (from memory - see your SET output).
However, judging from your descriptions there is no need for you
to change these defaults.
>
> Well, dont laugh, but I really dont need these log saves. I managed to
> save them to /dev/null.
Yes, the database does not check the target.
(And even if it would check: It cannot prevent anybody from using
the same tape again and again, or from throwing it away.)
About "not needing": That is your own decision, but most people
use a DB to store data of commercial (or emotional) value and hence
realize sooner or later how costly a loss is.
It is like "not needing" a seat belt when driving a car ...
> But if I think about that now: if the db wants to restore from these
> saved
> logs, it will fail terribly while reading from /dev/null. I will have
> to correct this situation.
It simply means that you can never use your log saves to re-apply
those changes that you did between "Save Data" and disk crash.
It depends on your organisation whether you can live with that
situation or cannot:
- if you have a read-only DB with data coming from some other
source, it probably is o.k.,
- if you enter data from telephone calls, it is not.
You can restore a "Save Data" without applying subsequent logs
_if_ that save is consistent, and that is guaranteed if you simply
do a "Save Data" in the "warm" state of the DB.
>
> > Did you read the manual ?
>
> Oh man, we really needed quick decisions!
> ;-)
> Not being an experienced Oracle, Adabas or Informix Admin, it took me
> a week to get our existing db running with adabas anyway...
> This is a lot more complex than that mysql-toy we use.
Yes - it is designed for "low cost of ownership" in an OLTP
environment, 7*24 operation ...
>
> But thanks a lot, you really helped me. You obviously know what you
> are talking about...
Thanks.
>
> Regards,
> Heiko.
>
> --
> -------------------------------------------------------------
> Heiko Stoermer mailto:Heiko.S...@Exklusiv.DE
> K&K Kommunikationssysteme Tel.: 0821/ 2589220
> Haunstetterstr. 19 Fax: 0821/ 2589222
> 86161 Augsburg WWW: http://www.exklusiv.de
--
Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany
(speaking only for himself)
mailto: jo...@sql.de