Great(?) news, FYI... the new "SHOW LOGPINNED" command is included in a 4.2.2 patch level (4.2.2.1) -- so now we can see who's gottit, and maybe free things up before the server crashes!
Don France Technical Architect -- Tivoli Certified Consultant San Jose, Ca (408) 257-3037 mailto:[EMAIL PROTECTED] Professional Association of Contract Employees (P.A.C.E. -- www.pacepros.com) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Seay, Paul Sent: Wednesday, June 19, 2002 5:47 PM To: [EMAIL PROTECTED] Subject: Re: DB backups Roll forward will even work in highly active environments, BUT, if you have one constipated turtle you are screwed. That can cause a log pin. Typically, it is the 286 PC that is running on a 1200 baud line with a 50% error rate from Afghanistan. You get the point. Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -----Original Message----- From: Remeta, Mark [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 19, 2002 12:05 PM To: [EMAIL PROTECTED] Subject: Re: DB backups Hi Dan, Roll forward mode would work unless you have as much activity as Wanda does. In that case you cannot use it because your log fills up to fast. Mark -----Original Message----- From: Daniel Sparrman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 19, 2002 6:58 AM To: [EMAIL PROTECTED] Subject: Re: DB backups Hi You don't have to do full backups every hour to be able to do point-in-time restore of the database. Having your recovery log in roll-forward mode, means that you don't have to backup your database. In case of a corrupt database, you just restore you're database that you have backed up earlier, and then tell TSM to do a point-in-time restore. This means that after TSM has restored the database from the tape, it will inspect the log, to see what transactions have been made after the database backup. This was what I was trying to explain in my last message. Using this scenario, you don't have to backup your database twice a day. Best Regards Daniel Sparrman ----------------------------------- Daniel Sparrman Exist i Stockholm AB Propellervdgen 6B 183 62 HDGERNDS Vdxel: 08 - 754 98 00 Mobil: 070 - 399 27 51 Remco Post <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 2002-06-18 11:35 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Re: DB backups Hi, The question is more, do you really want to be able to do a point-in-time restore of your database. In case of a real disaster, you'll probably be very happy if you get the server back to a state it was in 24 hours before the disaster. In case of database corruption, You'll probably cannot afford to restore 10 times just to find an approx point in time for the corrupting transaction, which is still in you log... I guess that maybe a few incremental db backups during the day would be good enough for most people. We just do two fulls every day, but then again, we have two separate robots for primary and copy pools... On Mon, 17 Jun 2002 15:04:12 +0200 "Daniel Sparrman" <[EMAIL PROTECTED]> wrote: > Hi > > You have to have your recovery log in "roll-forward" mode to be able > to do > a point-in-time restore of the database(up to the minute). > > This mean that the recovery log isn't purged at every write to the > database. Instead, the log is purged when a database backup occurs. This > means that you can restore your database "up to the second" it went down. > > Doing backups of the database every minute seems, how am I going to > put > it... Not the best solution. This is not a way to be able to restore the > database using point-in-time. > > Best Regards > > Daniel Sparrman > ----------------------------------- > Daniel Sparrman > Exist i Stockholm AB > Propellervdgen 6B > 183 62 HDGERNDS > Vdxel: 08 - 754 98 00 > Mobil: 070 - 399 27 51 > > > > > William Rosette <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 2002-06-17 > 14:52 Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > cc: > Subject: Re: DB backups > > > You can get "up to the minute" if you do enough database backups, and > I still don't understand the "up to the minute" idea. If you are > doing backups every minute that seems logical but do not most people > backup once > a night? and if there is a database backup is not this database backup and > "up to the day" same as "up to the minute?" > > > > "Jolliff, > Dale" To: [EMAIL PROTECTED] > <[EMAIL PROTECTED] cc: > OM> Subject: Re: DB backups > Sent by: > "ADSM: Dist > Stor Manager" > <[EMAIL PROTECTED] > IST.EDU> > > > 06/14/02 12:21 > PM > Please respond > to "ADSM: Dist > Stor Manager" > > > > > > > I have suggested this a couple of times, but have been told they need the > ability to restore the TSM server "up to the minute" that rollforward > provides. > > > -----Original Message----- > From: William Rosette [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 14, 2002 9:49 AM > To: [EMAIL PROTECTED] > Subject: Re: DB backups > > > We changed our roll forward to NORMAL and have seen very little (once > in a > year) crash due to full recovery log. This may be an option instead > of > the > type FILE. > > > > > "Jolliff, > Dale" To: [EMAIL PROTECTED] > <[EMAIL PROTECTED] cc: > OM> Subject: DB backups > Sent by: > "ADSM: Dist > Stor Manager" > <[EMAIL PROTECTED] > IST.EDU> > > > 06/14/02 10:01 > AM > Please respond > to "ADSM: Dist > Stor Manager" > > > > > > > Is anyone doing db backups to disk using devclass type FILE? > > I know, it's not necessarily a good thing, but right now we have a db that > is large enough that the log can fill before a full db backup can run. > > Before I set this up, I'm wondering if anyone else is doing this. -- Met vriendelijke groeten, Remco Post SARA - Stichting Academisch Rekencentrum Amsterdam http://www.sara.nl High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668 3167 "I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end." -- Douglas Adams Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately.
