| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Fw: Just got back from SQL*Server 2000 training...
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 waaaaay to much redo to contain. Since all the data
originates elsewhere recovery just means redoing a load. Any OLTP
should be in archivelog. If you run out of space roll the old archives
off to tape and delete from the filesystem. This is no where near the
comparison of truncating the txn log. If you need an old log you can
still get it back.
Single schema?? Depends on the application and its operation. We run multiple schemas on some of our databases and single schema on others. It's a matter of separating different apps or app functions from others. When it makes sense do it. When it doesn't don't. That's why we are DBA's to direct the deveolpers in how these things should be handled.
Rodd
On Tue, 2002-02-19 at 11:38, Jay Hostetter wrote:
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-
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.
>>> G.Plivna_at_itsystems.lv 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/
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:
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: jhostetter_at_decommunications.com
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: ListGuru_at_fatcity.com (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).
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rodd Holman INET: roddholman_at_HotPOP.com 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: ListGuru_at_fatcity.com (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).Received on Tue Feb 19 2002 - 11:58:46 CST
 |
 |