Lots of reply's to this one, with two basic theme's.
1) Why bother; Defragment works fine on a live box and many databases,
if properly managed, don't need it anyhow.
2) Good idea.
My conclusion: The use of defragment while there are no users and the DB's
are off-line does not appear to be strictly necessary, but, if you are
running the kind of system where such down time is possible, this is the
safest method and of course guaranteed not to impact on user perceived
performance.
So, I shall proceed as planned. No specific "gotchas" were raised other than
the concern that the servers may not come back up. Fortunately I have remote
console access so although a pain, this would not be a calamity. Any
problems, I shall report them. Thanks again.
Thanks to: (To mention but a few)
Jeff Hummel for
Defrag during downtime is the best way to do it. A competitor of ours didn't
and had to restore their database due to "corruption" about every 3 months.
After two occurrences they eliminated defragcron and never had another
corruption.
If you are using Oracle, you will notice that the datafiles and redo logs
should not become fragmented once they have been defragmented the first
time.
If using Oracle, be sure to clone the mount points where the Oracle home,
executables, and control files are located. This will insure that your
control files, logs, and temporary files are synchronized during a restore.
Pat O'Brien for
During my 4.0D rollout several years ago, I stumbled on a problem with
defragment where normally the system was crashed by defragment. I turned
off this feature and left off. About 2 years ago on 4.0F, we were doing to
many "manual" defrag's. We researched 4.0F defrag, and played with it for a
while. Eventually we enable the default 4.0f cron entry for defrag'ing all
filesystems. Several months later while reviewing collect output, we
realized cpu utilization became up abruptly when defrag started, and went
away when derfag stoped. The reason was every filesystem was trying to be
100% defrag'ed every night. realizing that this was less than ideal, we
changed the cron entry by adding a -t 95 which changed the threshold to only
defrag filesystems less than 95% perfect i/o. This has been working great
for us. We have roughly 30TB of storage on advfs filesystems with a average
size of 150 GB each. This has worked well on our 5.1 pk 3 systems as well,
though they are smaller systems (ES40) with about 1 TB each. Strictly from
a admin side, another change was made to the default 4.0F cron entry where
the start time was delayed by 1 minute, and a new cron entry was added to
echo the date ( date & time ) to the default defrag log file for readability
reasons. 5.X does this for you.
Bob Vickers for
I'm surprised you want to do all that...what are you afraid of? Why not just
run the defragment program on a live system?
I've not heard of the Tru64 defrag program corrupting data but killing
applications can definitely cause damage. There is also a significant chance
that the whole thing will get stuck somewhere (especially if you NFS at all)
and so the system will stay down until someone reboots it.
Andy Cohen for
I agree with the need to defrag periodically (what db are you using? I've
heard it said that Oracle doesn't cause fragmentation). My concern would be
rebooting with a script -- what happens if it shuts down but doesn't restart
successfully? That's happened to me and I've had to come in and push the
power button. There is hardware/software that can be added/configured to
let you do a cold boot (power cycle) remotely. This may be worth looking
into.
Colin Bull for
I guess if your databse is any good, and you allocate space correctly, it is
very rare that you need to defrag your disk at all for databases. Both
Oracle and Informix let you use raw disk, which can get over this problem
completely if you administer the tables properly.
Mike Deacy
Seems like a good plan to me. I suppose you can try it and see how this
schedule suits your fragmentation needs. I would also expect that
maintenance type operations are best done when a system is less busy. I'm
sure they'll complete faster and also not impact any production activity.
Kind regards
Lawrie Smith
Capita Technical Services
West Malling
email: lawrie.smith_at_capita.co.uk
Tel: 01732 877266
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
Received on Thu Mar 07 2002 - 09:28:19 NZDT