I have seen the latest and fastest computer causing log pin. Cause? due to
incorrect NIC setting, like 100 Half duplex, and/or incorrect setting at
the switch. Have u tried to backup using 10 MB with half duplex? I did,
it will drive u crazy.
Sung Y. Lee
E-mail [EMAIL PROTECTED]
"Seay, Paul"
<seay_pd@NAPTHEON To: [EMAIL PROTECTED]
.COM> cc:
Sent by: "ADSM: Subject: Re: DB backups
Dist Stor
Manager"
<[EMAIL PROTECTED]
.EDU>
06/19/2002 07:47
PM
Please respond to
"ADSM: Dist Stor
Manager"
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
Propellervägen 6B
183 62 HÄGERNÄS
Växel: 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
> Propellervägen 6B
> 183 62 HÄGERNÄS
> Växel: 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.
