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 commands, etc.  I learned this one the hard way.

Restricted activities-
You probably don't have to do this stuff on small SQL Server databases.

txn log -
Oracle isn't vulnerable when you are backing up/deleting archive logs.

single schema -
Sounds like some applications that we have had to install, which were developed by 
lazy programmers who weren't concerned about security.  You know, the ones that 
require a single user with full DBA rights.

>>> [EMAIL PROTECTED] 02/19/02 11:08AM >>>
I sent this e-mail to a friend who works with SqlServer and he sent this to
a SqlServer list as You can see from headers

Here are comments of a member :-))))))))

Gints Plivna
IT Sisttmas, Merfena 13, LV1050 Rega
http://www.itsystems.lv/gints/ 



----- Original Message -----
To: "SQL 7 Discussions" <[EMAIL PROTECTED]>
Sent: Tuesday, February 19, 2002 5:29 PM


My two cent's prefaced by >>>>>>.  I'm not an Oracle expert, and my answers
reflect my limited (5 years) experience as a DBA...


*Row size cannot span multiple 8k pages, therefore max row size = 8k
>>>>>> I've yet to see a properly designed database that needs more
>>>>>> than this.  Unless he/she doesn't understand that text/image
>>>>>> data is stored separately

*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?

*Txn logs not mirrored.  Must rely on RAID or other mirroring software.
>>>>>> Hardware RAID/mirrors are much better than software, so if
>>>>>> you are comparing Oracle software based mirrors to the
>>>>>> hardware based ones we use then our way is much faster

*Separate permissions for RI checking.  Requires two permission grants if
foreign key exists - one for child table and one for parent table.  Called
REFERENCES permission.
>>>>>> No comment.  Not sure what he's after here.

*Recommended that ALL production objects owned by DBO - not conducive to
multi-schema instances.
>>>>>> This is just a best-practices item.  It works both ways.  I
>>>>>> personnally find it easier to use Oracle when everything is
>>>>>> owned by one user.

*Activities that are restricted during backups:
1.  Creating or modifying databases.
2.  Performing autogrow operations.
3.  Creating indexes.
4.  Performing nonlogged operations.
5.  Shrinking a database.
>>>>>> I've not found this to be a limitation.  How often do you actually
>>>>>> do these tasks on a production database, anyways?

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.

*When txn log fills up, have to just "truncate" the log in order for
processing to continue.  Leaves system vulnerable until you get a full DB
backup.
>>>>>> Seems a little like disk space filling up in Oracle.  How is this
>>>>>> different?

*If you have a 100GB DB that is full, your backup will be 100GB.  No
compression of backups!
>>>>>> Valid point here.  But I'd rather not trust my backup to a
>>>>>> compression scheme anyways.



--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Jay Hostetter
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to