of TSM DB DIR
became corrupt and DB is in roll forward mode (need help)
Hello John,
See both Admin Guide and Admin Reference regarding dsmserv restore db. There
are two recovery methods : on that deletes the logs (point in time restore,
ignore it) and one that keeps and rollforwards the logs
Long story short, I have a full DB backup taken on a linux system running TSM
6.3.4.300 with the DB in roll forward mode. The DB is spread across 4 different
dbdirs file systems. One of the file systems became corrupt and I need to
recover the DB from the full backup.
I have the dbdirs file
...@duqlight.com a écrit :
Long story short, I have a full DB backup taken on a linux system
running TSM 6.3.4.300 with the DB in roll forward mode. The DB is
spread across 4 different dbdirs file systems. One of the file systems
became corrupt and I need to recover the DB from the full backup.
I have
Why do I need the recovery log to be in roll-forward mode in order to restore a single
volume of my database?
Roll forward mode recovers a database to the point in time of the now versus
normal as of the last backup + incrementals. The other database volumes
still on disk are at current time. To end up with a consistent database you
must have a way to bring all to current. The roll-forward replays
mode?
I operate in roll-forward mode all the time, and the max consumption on my
log is about 60%.
Tab, I've noticed my log consumption go way up when there is a lot of
database activity. I am in normal mode. I had to stop doing expiration
processing while the nightly backups from the clients w
forward mode but am not sure if the log size is
sufficient. Does anyone have any experience with switching in mid stream? I
have about 120 clients, I do have a space trigger set for both the DB and
log.
I'd also like to know if anyone thinks my (BufPoolSize131072) is a
bit low. I discovered my
to be good for a 9 gig DB. Adjust your DB backup trigger
(q stat) to something like 70 or 80% and test is for several days.
rv
-Message d'origine-
De : Gill, Geoffrey L. [mailto:[EMAIL PROTECTED]]
Envoy : mardi 17 avril 2001 17:07
: [EMAIL PROTECTED]
Objet : Roll Forward Mode
Here
: Roll Forward Mode
Here is a little of my environment that might help answer this question:
TSM 4.1.2
AIX 4.3.3
3494lib with 4 3590-E1A's
Database:
Available Space (MB): 18,000
Assigned Capacity (MB): 18,000
Maximum Extension (MB): 0
Maximum Reduction (MB): 8,740
[mailto:[EMAIL PROTECTED]]On Behalf Of
Gill, Geoffrey L.
Sent: Tuesday, April 17, 2001 9:07 AM
To: [EMAIL PROTECTED]
Subject: Roll Forward Mode
Here is a little of my environment that might help answer this question:
TSM 4.1.2
AIX 4.3.3
3494lib with 4 3590-E1A's
Database:
Available Space
Geoffrey,
Switching to roll-forward mode can be done at any time. As Wanda said, it
kicks off a full database backup to allow it to zero the log at a known
point.
Once in roll-forward mode, database changes will accumlate in the recovery
log until the next DB backup so log consumption will go
I'm curious about one thing though. When in "normal" mode,
log consumption
rarely should exceed about 1%. Yet your statistics show a max
utilization
of 89.3%. How did you do that in NORMAL mode?
Tab,
This is an excellent question. I was out all last week so I'm not sure what
happened. I
I've had a log max out at 5GB in normal - due to one very slow running
client (love those duplex mismatches!). The client backup ran almost all
day, and we were doing some Delete Filespaces, which hit the log/db pretty
hard. Since the log is flushed FIFO (see note), and the client session
13 matches
Mail list logo
