Archivelog mode -
I don't like putting test databases in archivelog mode. Or databases that are updated
once a day. Redo logs are adequate to recover from a power system failure.
Mirroring -
The problem with relying on hardware mirroring is that it mirrors everything -
corruption, delete
Well there is no arguement there if he is willing to live
with all MS limitations by saying I don't expect to do this...
I can live with this... blah blah...
Rich
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: Fw: Just
Couldn't resist responding to this.
*Cannot take DB out of archivelog mode. Can limit what is posted to txn
log, but cannot stop it.
Why would you want to? So you have the remote possibility
of ending up with a corrupt, unrecoverable database if the
power supply on the system fails?
JS:
We run a couple of production systems in noarchivelog. This is due to
how they operate. They are reporting datamarts and the nightly loads
would generate way to much redo to contain. Since all the data
originates elsewhere recovery just means redoing a load. Any OLTP
should be in
Sounds like the M$ Brainwashing has taken root.
:-)
John
[EMAIL PROTECTED] wrote:
Well there is no arguement there if he is willing to live
with all MS limitations by saying I don't expect to do this...
I can live with this... blah blah...
Rich
From: [EMAIL PROTECTED]
Reply-To:
See below...
Backups directly to tape require the tape to be attached
locally to SQL Server.
Okay, if you really want to transfer your 10+GB
database over the
network each night, I suppose you will need to use Oracle.
JS: 10+GB over the network is trivial. If you are using
Jared,
I was going to respond, but you did a great job for me. Your points were my points
exactly. I really tried to go to the SQL*Server class with an open mind thinking I'm
adding a skill set, but I found myself constantly comparing to Oracle. I didn't mean
to start the Holy War again,
