Pre-paid refund on porting out

"Michael" <[email protected]> wrote in message
news:[email protected]
>>> Point in time is not "Ill pick a time and you make it happen"
>>
>> Funny how IBM seem to disagree with you.
>>
> http://publib.boulder.ibm.com/infoce...jsp?topic=/com.
> ibm.db2tools.adb.doc.ug/c18spit.htm
>>
>> Are you actually stupid enough to think that you know more than IBM
>> when it comes to DB2?
>
> I did go to the link, and it proves what I said. A point-in-time
> backup is a point-in time.
>

*Any* point in time.

> You back it up at 2200, if it falls over at 900 following morning you
> cant roll back to say 647am
>

Wrong.

> You can restore to your point-in-time, which is 2200
>
> Quoted:
> Specifying a point in time to which to recover
> To set up a batch job that will specify a particular time to which to
> recover the DB2 subsystem:

Can't you even comprehend what you are reading, you useless ****?
"To set up a batch job that will specify a particular time to which to
recover the DB2 subsystem"

What would be the purpose of specifying a "particular time to which to
recover the DB2 subsystem" if, as you claim, the only point in time to which
you can recover is the point in time that the last backup was taken?

You're getting sillier by the minute.

--
Kwyj

---

› See More: Pre-paid refund on porting out

"Michael" <[email protected]> wrote in message
news:[email protected]
>>>> You complete ****ing idiot. That won;t give you anything like point
>>>> in time recovery.
>>>> If you back up a table at (for example) 22:00 each night and I tell
>>>> you I want it restored to the state it was in at 10:00 this morning
>>>> how are you going to do that using table backups?
>>>
>>> In case you dont know what a "point in time" is, its, well, a,
>>> "point in time".
>>
>> It is *any* point in time in the past, ****wit.
>
> Sorry buddy, the capital A in "A point in time", means one.

And it doesn't have to correspond to a backup, stupid.

>
> A = single article
>
>>> So if you backup your DB at 22:00 every night, and you want a backup
>>> to a point in time, you get to choose which 22:00 you want it backed
>>> up to. today, yesterday, whatever you want
>>
>> Wrong again.
>>
>>>
>>> Point in time is not "Ill pick a time and you make it happen"
>>
>> Funny how IBM seem to disagree with you.
>>
> http://publib.boulder.ibm.com/infoce...jsp?topic=/com.
> ibm.db2tools.adb.doc.ug/c18spit.htm
>>
>> Are you actually stupid enough to think that you know more than IBM
>> when it comes to DB2?
>
> occasionally. ive proved them wrong every now and again
>

Yeah, right........

>>> You can always choose to have a disaster recovery site where every
>>> transaction is backed up as it happens. Then you can restore to
>>> whatever time you like.
>>>
>>>> You can't. You have to restore the table to it's state at the
>>>> previous backup, then replay the transaction logs up until the
>>>> point in time I have
>
> So what happens in Knox then, hmmm????

SAN replication which is totally different to backup, ****wit.

> Riddle me that, ****wit
>
>>> Thats what a "point in time" backup is, chuckles
>>>
>> Try telling that to IBM, moron.
>
> They know exactly how it works, they do point in time backups once a
> day, at night, and on Sunday nights as well
>

Which has **** all to do with what point in time they are capable of
restoring to.

--
Kwyj

On Sat, 06 May 2006 13:42:47 GMT, "Michael" <[email protected]> wrote:

>> >> You complete ****ing idiot. That won;t give you anything like point
>> >> in time recovery.
>> >> If you back up a table at (for example) 22:00 each night and I tell
>> >> you I want it restored to the state it was in at 10:00 this morning
>> >> how are you going to do that using table backups?
>> >
>> > In case you dont know what a "point in time" is, its, well, a, "point
>> > in time".
>>
>> It is *any* point in time in the past, ****wit.
>
>Sorry buddy, the capital A in "A point in time", means one.
>
>A = single article

Actually:

A = indefinite article
The = definite article

"Kwyjibo." <[email protected]> wrote in message
news:[email protected]...
> "Michael" <[email protected]> wrote in message
> news:[email protected]
> >>> Point in time is not "Ill pick a time and you make it happen"
> >>
> >> Funny how IBM seem to disagree with you.
> >>
> >
http://publib.boulder.ibm.com/infoce...jsp?topic=/com.
> > ibm.db2tools.adb.doc.ug/c18spit.htm
> >>
> >> Are you actually stupid enough to think that you know more than IBM
> >> when it comes to DB2?
> >
> > I did go to the link, and it proves what I said. A point-in-time
> > backup is a point-in time.
> >
> *Any* point in time.

If you do a point in time back up at 0900, 1000, and 1100, you cant go back
in time to 1017 - does that make it clearer?
You can go back to the point in time in which you backed up from - being
0900, 1000, or 1100

> > You can restore to your point-in-time, which is 2200
> >
> > Quoted:
> > Specifying a point in time to which to recover
> > To set up a batch job that will specify a particular time to which to
> > recover the DB2 subsystem:
>
> Can't you even comprehend what you are reading, you useless ****?
> "To set up a batch job that will specify a particular time to which to
> recover the DB2 subsystem"

Which has to match the point in time that you backed up from - read the rest
of the section about making the backup, and recovering the backup

> What would be the purpose of specifying a "particular time to which to
> recover the DB2 subsystem" if, as you claim, the only point in time to
which
> you can recover is the point in time that the last backup was taken?
>
> You're getting sillier by the minute.

I assume you cant read simple English then

>
> --
> Kwyj
>
>

"Kwyjibo." <[email protected]> wrote in message
news:[email protected]...
> "Michael" <[email protected]> wrote in message
> news:[email protected]
> >>>> You complete ****ing idiot. That won;t give you anything like point
> >>>> in time recovery.
> >>>> If you back up a table at (for example) 22:00 each night and I tell
> >>>> you I want it restored to the state it was in at 10:00 this morning
> >>>> how are you going to do that using table backups?
> >>>
> >>> In case you dont know what a "point in time" is, its, well, a,
> >>> "point in time".
> >>
> >> It is *any* point in time in the past, ****wit.
> >
> > Sorry buddy, the capital A in "A point in time", means one.
>
> And it doesn't have to correspond to a backup, stupid.

Of course it does. How can you restore back to a point in time if you didnt
backup at that time.

Why dont you look at a few ARPs for various applications? If they dont have
a live DR site, then they all have recovery plans which state "within x
hours, recover database back to last backup before disaster occurred" ie.
you backup at 1200am and 1200pm, and disaster happens at 245pm, vendor has
12 hrs to recover back to the 1200pm backup

> > A = single article
> >
> >>> So if you backup your DB at 22:00 every night, and you want a backup
> >>> to a point in time, you get to choose which 22:00 you want it backed
> >>> up to. today, yesterday, whatever you want
> >>
> >> Wrong again.
> >>
> >>>
> >>> Point in time is not "Ill pick a time and you make it happen"
> >>
> >> Funny how IBM seem to disagree with you.
> >>
> >
http://publib.boulder.ibm.com/infoce...jsp?topic=/com.
> > ibm.db2tools.adb.doc.ug/c18spit.htm
> >>
> >> Are you actually stupid enough to think that you know more than IBM
> >> when it comes to DB2?
> >
> > occasionally. ive proved them wrong every now and again
> >
> Yeah, right........

All hail IBM, eh?
If you never managed to prove them wrong about anything then that shows your
lack of knowledge

"Michael" <[email protected]> wrote in message
news:[email protected]
> "Kwyjibo." <[email protected]> wrote in message
> news:[email protected]...
>> "Michael" <[email protected]> wrote in message
>> news:[email protected]
>>>>> Point in time is not "Ill pick a time and you make it happen"
>>>>
>>>> Funny how IBM seem to disagree with you.
>>>>
>>>
> http://publib.boulder.ibm.com/infoce...jsp?topic=/com.
>>> ibm.db2tools.adb.doc.ug/c18spit.htm
>>>>
>>>> Are you actually stupid enough to think that you know more than IBM
>>>> when it comes to DB2?
>>>
>>> I did go to the link, and it proves what I said. A point-in-time
>>> backup is a point-in time.
>>>
>> *Any* point in time.
>
> If you do a point in time back up at 0900, 1000, and 1100, you cant
> go back in time to 1017 -

That's strange, because I did precisely that with a SQL database only last
week.(not to 10:17 but to a time that didn't correspond with a backup)
The same principle applies to DB2. You restore the DB then replay any
transactions that took placed between the time you took the backup and the
time you want to restore to. Quite simple to anyone with even the most basic
idea of how databases work.

RESTORE DATABASE xxx FROM yyy WITH NORECOVERY
RESTORE LOG xxx FROM yyy WITH NORECOVERY
.....
.....
RESTORE LOG xxx FROM yyy WITH STOPAT = datetime

Care to explain what the STOPAT directive in the above SQL does?

Are you suggesting I have done the impossible?

> does that make it clearer?

It makes the fact that you don't have a clue much clearer.

> You can go back to the point in time in which you backed up from -
> being 0900, 1000, or 1100

Or any time in between.
http://publib.boulder.ibm.com/infoce...p_restore.html
or http://tinyurl.com/l4myq :
"As part of normal operation, DB2 creates transaction logs that record
changes to the database."
"If you want to retain logs and perform online backups, it is essential that
you backup the transaction log files themselves. This is because the backup
logs let you replay the transactions recorded in the log files against a
refreshed copy of the database."

Looks like you ****ed up AGAIN. (Why am I not surprised.....)

>
>>> You can restore to your point-in-time, which is 2200
>>>
>>> Quoted:
>>> Specifying a point in time to which to recover
>>> To set up a batch job that will specify a particular time to which
>>> to recover the DB2 subsystem:
>>
>> Can't you even comprehend what you are reading, you useless ****?
>> "To set up a batch job that will specify a particular time to which
>> to recover the DB2 subsystem"
>
> Which has to match the point in time that you backed up from

Bzzzt. Wrong.

>- read
> the rest of the section about making the backup, and recovering the
> backup
>
>> What would be the purpose of specifying a "particular time to which
>> to recover the DB2 subsystem" if, as you claim, the only point in
>> time to which you can recover is the point in time that the last
>> backup was taken?
>>
>> You're getting sillier by the minute.
>
> I assume you cant read simple English then

And I'm assuming you don't have the slightest idea what you are waffling on
about.

If you still aren't convinced, try asking someone who knows something of DB2
before wasting any more of my time with your mindless ****.

--
Kwyj

"Michael" <[email protected]> wrote in message
news:[email protected]
> "Kwyjibo." <[email protected]> wrote in message
> news:[email protected]...
>> "Michael" <[email protected]> wrote in message
>> news:[email protected]
>>>>>> You complete ****ing idiot. That won;t give you anything like
>>>>>> point in time recovery.
>>>>>> If you back up a table at (for example) 22:00 each night and I
>>>>>> tell you I want it restored to the state it was in at 10:00 this
>>>>>> morning how are you going to do that using table backups?
>>>>>
>>>>> In case you dont know what a "point in time" is, its, well, a,
>>>>> "point in time".
>>>>
>>>> It is *any* point in time in the past, ****wit.
>>>
>>> Sorry buddy, the capital A in "A point in time", means one.
>>
>> And it doesn't have to correspond to a backup, stupid.
>
> Of course it does. How can you restore back to a point in time if you
> didnt backup at that time.

I've already covered this, but as you appear to be too stupid to have
comprehended it the first time I'll go over it again.

You can recover to *any* point in time by restoring a backup then replaying
the transaction logs up until the point in time to which you want to
recover. DB2 creates these logs by default (despite your mindlessly idiotic
claim that they don't exist)
http://publib.boulder.ibm.com/infoce...p_restore.html
"As part of normal operation, DB2 creates transaction logs that record
changes to the database."


>
> Why dont you look at a few ARPs for various applications? If they
> dont have a live DR site, then they all have recovery plans which
> state "within x hours, recover database back to last backup before
> disaster occurred" ie. you backup at 1200am and 1200pm, and disaster
> happens at 245pm, vendor has 12 hrs to recover back to the 1200pm
> backup
>
>>> A = single article
>>>
>>>>> So if you backup your DB at 22:00 every night, and you want a
>>>>> backup to a point in time, you get to choose which 22:00 you want
>>>>> it backed up to. today, yesterday, whatever you want
>>>>
>>>> Wrong again.
>>>>
>>>>>
>>>>> Point in time is not "Ill pick a time and you make it happen"
>>>>
>>>> Funny how IBM seem to disagree with you.
>>>>
>>>
> http://publib.boulder.ibm.com/infoce...jsp?topic=/com.
>>> ibm.db2tools.adb.doc.ug/c18spit.htm
>>>>
>>>> Are you actually stupid enough to think that you know more than IBM
>>>> when it comes to DB2?
>>>
>>> occasionally. ive proved them wrong every now and again
>>>
>> Yeah, right........
>
> All hail IBM, eh?

Not at all, but on a topic as basic as this it's pretty hard to **** it up
(although you've managed to do just that)

> If you never managed to prove them wrong about anything then that
> shows your lack of knowledge

ROFL.
Keep trying, lightweight.


--
Kwyj