-
Originally posted by hrishy
pando can you please explain what do you mean by the above statement..well all oracle9i boasts about this OMF feature..why do you think its bad ?
can you elaborate
regards
Hrishy
Hi Hrishy,
The point is no one will want to put all its datafiles on one volume defined by DB_CREATE_FILE_DEST for a production database.
Yes, you can dynamically change this parameter but it invloves same amount of work compared to manually mentioning the path.
Also the filenames assigned by OMF is a bit complex.
Sanjay G.
Oracle Certified Professional 8i, 9i.
"The degree of normality in a database is inversely proportional to that of its DBA"
-
Be careful about 'noone'.
I have four Oracle and about 15 SQL Server databases which are all allocated to a single mount point. One of the Unix Oracle's is 2TB. (Okay, it has two mount points, one of which is for read only tablespaces.) There is an NT Oracle that is 750GB on one mount point.
We are using EMC. You can't load balance a single pipe with an 8 GB data buffer. And it can greatly simplify file management.
Joseph R.P. Maloney, CSP,CDP,CCP
'The answer is 42'
-
The point is no one will want to put all its datafiles on one volume defined by DB_CREATE_FILE_DEST for a production database.
The point is: simplify the work of the DBA. Let the mirroring and multiplexing with the system administrator on the OS level. "Why should a superior being like a DBA worry with those insignificant OS file issues?"
Anyway, OMF seems useless for people who likes a little organization and perfect for those lazy DBA's who don't even remember where they put their own datafiles. Sounds like crap.
As pando says, Oracle itself recommends OMF for test databases.
An ounce of action is worth a ton of theory.
—Friedrich Engels
-
You can use OMF for Production database, especially if you are using SAME (Strip And Mirror Everything), under a single mount point, and as jrpm said, using an EMC array, you've already distributed your I/O.
Nothing wrong with OMF under this configuration.
Next I'll be hearing that if a Buffer_cache_ratio < 96% your database is performing badly.
ALTHOUGH, redo logs are a different story, YOU MUST multiplex your redo logs, don't rely on OS Mirroring, cause if you have an error writing the the log... this error is MIRRORED and you're stuffed.
OCP 8i, 9i DBA
Brisbane Australia
-
You can use OMF for Production database, especially if you are using SAME (Strip And Mirror Everything), under a single mount point, and as jrpm said, using an EMC array, you've already distributed your I/O.
Nothing wrong with OMF under this configuration.
Yeah, it works. But personally I feel losing control on datafiles when using OMF, it's like a black box. Naming convention doesn't help too. IMHO, OMF does not decrease DBA efforts so much to completely justify its adoption. That's the point.
ALTHOUGH, redo logs are a different story, YOU MUST multiplex your redo logs, don't rely on OS Mirroring, cause if you have an error writing the the log... this error is MIRRORED and you're stuffed.
That's not a problem. OMF can multiplex redo logs and control files with DB_CREATE_ONLINE_LOG_DEST_n.
An ounce of action is worth a ton of theory.
—Friedrich Engels
-
Originally posted by adrianomp
Yeah, it works. But personally I feel losing control on datafiles when using OMF, it's like a black box. Naming convention doesn't help too. IMHO, OMF does not decrease DBA efforts so much to completely justify its adoption. That's the point.
That's not a problem. OMF can multiplex redo logs and control files with DB_CREATE_ONLINE_LOG_DEST_n.
So you're saying, if your running OMF, you don't know where your Datafiles are? How are you losing control? What, just because you're not naming the datafiles yourself? Really, you stil lmonitor the tablespace via OEM...the name of the file shouldn't make any difference.
I think it's a personal choice, I don't think OMF is a good or bad idea, it can be useful in situations, i.e. SIngle Mount Point, EMC arrays.
I don't think it's related to whether or not its a PROD or TEST db. Why admister your TEST DB differently to your production environment?
OCP 8i, 9i DBA
Brisbane Australia
-
well we must administer our development boxes differently from production boxes, we dont have same server, same disks, same file systems setups
we have customers who use a massive box as production box and for development they use a PC heh
-
Originally posted by pando
we have customers who use a massive box as production box and for development they use a PC heh
Volume testing must be... well, interesting to say the least.
OCP 8i, 9i DBA
Brisbane Australia
-
This thread is going nowhere..............
Agasimani
OCP(10g/9i/8i/8)
-
Hi Pando
Thank you very much for an answer..thanks to larry too..please make databases complex..and diificult to manage..so that every oracle shops would always need a DBA ;-D
regards
Hrishy
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|