Can the PreserveDbOnExit be changed on the fly so that it can be
turned on as part of controlled reboot, then left off in case of a
crash?
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Bell, Charles (Chip)
Sent: Wednesday, July 09, 2008 10:48 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Journaling database retaining upon reboot?
Well, I have to have some relief here, considering there's nothing that I can
do about the setup. That means after they are using all 36 mount point
(millions of files each), and there's a reboot, 36 different backups with
journaling are going to have to start from scratch. Not only is that
terrible, but there's nothing I can do about it! So for those reading this,
what would you do in my situation, set PreserveDbOnExit to 1 or 0?
The TSM client host in question has 36 NTFS mount points, each will 5
million+ files. Per IBM TSM Support recommendations, I set the host machine
up with a TSM node for each mount point (therefore, 36), and configured
journaling for each mount point as well. All per their guidelines and
instruction. The application (an imaging app) on the host machine writes to a
mount point until reaching a 80% utilized threshold, and then begins writing
to the next numerical mount point. Last February, they started with mount
point 1, and now they are on 12. That means when they patched the machine
last night and rebooted, several backups have failed with memory errors, and
there are 4 running right now, each just spinning their wheels on directories
that mostly unchanged. I am really trying to remain calm, though it's
sickening to think that there is simply nothing that I can do about it. :(
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Andrew Raibeck
Sent: Wednesday, July 09, 2008 11:42 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Journaling database retaining upon reboot?
> Sooo...with all of these issues with jbb, are they being worked
> on/fine-tuned?
Yes and no.
For the case where you use PreserveDbOnExit=1 and the journal service is
shut down for some period of time, the behavior will remain unchanged. Use
at your own risk. If the journal service is down, it cannot effectively
monitor file system changes so there is no known solution for this.
For the journal corruption issue, we are currently targeting an
enhancement that allows the journal service to know whether the database
was closed cleanly (by a clean journal service shutdown). Upon restart, if
the journal service does not detect the "I was closed cleanly" flag in the
journal database, it will effectively ignore PreserveDbOnExit=1 and reset
the journal database, as if PreserveDbOnExit=0 was in effect. This would
be in a future release of the product. Note that this does not represent a
formal announcement or commitment, so this is subject to change.
A THEORETICALLY cleaner solution could include implementation of of a
journal database with transactional capabilities, including rollback, more
thorough structural integrity checking, etc. Even in a rollback scenario,
in-flight file system changes would be lost (like the case where you use
PreserveDbOnExit=1 and journal service is down for some period of time),
leaving a less than perfect solution. But this is all hypothetical, and
there are no plans in place.
Best regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
IBM Tivoli Storage Manager support web page:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.
html
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/09/2008
09:02:05 AM:
> The way the downtime for this particular machine goes, there should be
no
> file system changes occurring.
>
> Sooo...with all of these issues with jbb, are they being worked
> on/fine-tuned?
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Andrew Raibeck
> Sent: Wednesday, July 09, 2008 10:40 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Journaling database retaining upon reboot?
>
> While the journal service is down, any file system changes are not
> tracked. If a file changes while the journal service is down, it will
not
> be backed up until either another full (non-journaled) backup runs, OR
the
> file changes again and the journal service is able to track it at that
> time.
>
> If the journal service is not shut down cleanly (e.g., a cluster
failover
> in a cluster setup, or something else that causes the journal to not
shut
> down cleanly), the journal database might be in an inconsistent
> ("corrupt") state, after which behavior is unpredictable.
"Unpredictable"
> could run the gamut of files not getting backed up when they should or a
> journal service crash when the corruption is encountered.
>
> So PreserveDbOnExit=1 should only be used when you know you can stop the
> journal service cleanly and you expect it to start shortly thereafter
> (like in a controlled reboot scenario).
>
> Best regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Product Development
> Level 3 Team Lead
> Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> Internet e-mail: storman AT us.ibm DOT com
>
> IBM Tivoli Storage Manager support web page:
>
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.
> html
>
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/09/2008
> 08:09:54 AM:
>
> > Yes, that's it. You set it to 1 if you want it to retain/preserve
after
> going
> > offline.
> >
> > I wonder why IBM recommended I keep it to zero in my situation?
> >
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> > Behalf
Of
> > Erwann Simon
> > Sent: Wednesday, July 09, 2008 9:38 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: [ADSM-L] Journaling database retaining upon reboot?
> >
> > Hi Charles,
> >
> > Look at the PreserveDbOnExit parameter of the tsmjbbd.ini
configuration
> > file.
> >
> > As a general reference about JBB, read the FAQ :
> > http://www-1.ibm.com/support/docview.wss?uid=swg21155524
> >
> > --
> > Best regards / Cordialement / مع تحياتي
> > Erwann SIMON
> >
> > Bell, Charles (Chip) a écrit :
> > > I have a machine that has 36 NTFS Mount Points, each with millions
of
> > files.
> > > Since they are all hosted on the same machines, TSM Support highly
> > > recommended setting up a node for each, and to have TSM journal
each.
> Now I
> > > am running into a situation where every time that machine is
rebooted
> for
> > > patches/etc., the incrementals have to rebuild the journal database.
> Is
> > there
> > > a way to avoid that, as I am only 1/3 of the way through the Mount
> Point
> > > Usage (They have only used 12 of the 36 thus far). Please help. J
> > >
> > >
> > >
> > > God bless you!!!
> > >
> > > Chip Bell
> > > Network Engineer I
> > > IBM Tivoli Certified Deployment Professional (ITSM)
> > > Baptist Health System
> > > Birmingham, AL
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > -----------------------------------------
> > > Confidentiality Notice:
> > > The information contained in this email message is privileged and
> > > confidential information and intended only for the use of the
> > > individual or entity named in the address. If you are not the
> > > intended recipient, you are hereby notified that any dissemination,
> > > distribution, or copying of this information is strictly
> > > prohibited. If you received this information in error, please
> > > notify the sender and delete this information from your computer
> > > and retain no copies of any of this information.
> >
> > --------------------------------------------------------------
> > Ce message ne contient aucun virus connu. http://www.astaro.fr
> >
> >
> > --------------------------------------------------------------
> > Ce message ne contient aucun virus connu. http://www.astaro.fr
|
