Databases simply do not manipulate files very much, which is one reason why logical volumes (a.k.a. “raw devices”) are a viable option for databases. Databases do not add and drop files frequently. They do not grow often and rarely shrink. For the most part, database files are added only occasionally, rarely if ever removed, are large in size and are few in number. So, any test case the sysadmin puts together should emulate this behavior.
on 11/27/03 6:59 PM, Sujatha Madan at [EMAIL PROTECTED] wrote:
Hi,
Does anyone here do an O/S level defrag of their Oracle filesystems???
Background: (Tru64/8.1.7.4)
Sysadmin here were adamant that the Oracle domains were running out of extents and were highly fragmented (O/S level). DBA was adamant that the Oracle filesystems should not be defragmented. I lost the battle and the sysadmins are defragging the domains.
I now have a corruption on a table partition with 100 million plus rows on a 50G datafile. I am wondering if the defrag has caused this corruption.
The only way I can think of finding out is:
Finding the approx date of the corruption using the query
SELECT ROWID, <LAST_COLUMN_OF_TABLE> from <TABLE_NAME(PARTITION)>;
(which will do the full tablescan row by row).
And then finding when the defrag utility was hitting the particular datafile that is corrupted.
But this reasoning is flawed ...
Does anyone have another method of trying to pinpoint if the O/S defrag caused the corruption????
Regards,
Sujatha
