| 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: Defrag tool on the Oracle database server
testosterone_man says:
Real database servers using RAID 0 with no mirroring
... lol.
Maybe someone pointed the OEM "Tablespace Viewer" tool at a tablespace, saw uniform-sized extents for a segment scattered about and wanted them close together for fast full index scans or something?
token referral to Juan Loiza paper on "howto stop defragmenting ..."
If your datafiles are on a filesystem not used for other files (like archvied redo logs) and you're throwing a datafile once and only adding new datafiles, how is the filesystem possibly going to fragment?
By running a defragmenting tool on it, of course!
<rant, not really related>
A sysadmin should not have access to the live data
files (or their filesystems) at all. What could he/she
possibly do for live datafiles other than crash your
instance or take a tablespace offline? Nothing.
segregate files onto their own filesystems.
allow access to the filesystems by least privilege for
only the required actions. In other words, don't allow
the account used for backups to be able to restore
over good files. when and if its time for a restore
job (like when you are testing
backup/restore/recovery) either use a separate
filesystem, use a different account for restores, or
temporarily grant the account privileges to write to
the necessary directories, then revoke it as soon as
the exercise is completed.
just last week, a new sysadmin ran a restore job for me for a web server. a security template application went bad (conflict between local and domain policies) and I wanted to restore the prior configuration. simple enough, as a full backup was taken prior to locking the system down.
he neglected to de-select the servers that were not supposed to be included in the restore job (of the single server). part of a file server's filesystems that were covered by a backup set on the same tape got a taste of dbms_flashback (2 days prior) in an irreversible fashion. no one noticed yet. (Hi Alan).
our sysadmins don't have the oracle account passwords on our oracle servers. they do have the local administrator account, but that doesn't gain them access directly to the oracle datafile filesystems. They would have to first grant themselves access, which would appear in the security logs. Yes, they could clear the security logs, but most NT admins have never read a security log, so there is a good chance that they wouldn't think of looking there. Ideally, that would be reported by a syslog client to a linux server, but I haven't pushed that one forward yet ...
we use a staging server for backups.
the network backup jobs pickup backup sets from that
server, and have no permissions to access filesystems
on any oracle server.
If the backup sets make it to the staging server, its
the Network guys responsibility.
If the backup sets don't make it to the staging
server, its my responsibility.
back to the point ... the sysadmin shouldn't have enough permissions on the datafiles' filesystem to fragment/defragment the datafiles in the first place.
Pd
> on 2/6/04 1:46 PM, Freeman, Donald at
> dofreeman_at_state.pa.us wrote:
>
> > I just asked this a little while ago. We were
> using a trial version of =
> > diskkeeper at midnight for several months and it
> didn't hurt anything =
> > but I think potentially it could if the database
> is active. The question =
> > came up when we had to decide whether or not to
> buy it: What's going to =
> > happen when Oracle and this thing start tusslin'
> over a file? We =
> > stopped doing it.
> >
> > My data drives are badly fragmented now because we
> also stored backups =
> > in the unused space and add and delete them all
> the time. We are moving =
> > to a SAN in the next couple of months so we are
> leaving well enough =
> > alone and in the future will make sure that the
> drives I have data on =
> > only have Oracle files. I think Oracle can manage
> its own files well =
> > enough to avoid fragmentation.=20
> >
> > If you want to try this I would take the database
> down first. I would =
> > think that would be relatively safe. I believe
> there is some stuff on =
> > this on metalink. Oracle, of course, is not going
> to give you anything =
> > like an 'OK' for you to do this. I think what
> they said was that there =
> > isn't any need to do defrag from an Oracle
> standpoint.
> >
> >
> >
> > -----Original Message-----
> > From: oracle-l-bounce_at_freelists.org
> > [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of
> Michael Fontana
> > Sent: Friday, February 06, 2004 3:35 PM
> > To: oracle-l_at_freelists.org; ORACLE-L_at_fatcity.com
> > Subject: RE: Defrag tool on the Oracle database
> server
> >
> >
> > I think this depends upon whether you really like
> this guy or not.
> >
> > If you do, research to see whether or not it will
> affect Oracle (I'd bet
> > it will, and it will not be a good thing).
> >
> > If you don't like him, tell him to go right ahead,
> and don't research it
> > at all....
> >
> >
> > Michael Fontana
> > Sr. DBA
> > NTT/Verio
> >
> >
> >
> > -----Original Message-----
> > From: oracle-l-bounce_at_freelists.org
> > [mailto:oracle-l-bounce_at_freelists.org] On Behalf
> Of
> > Luc.Demanche_at_astrazeneca.com
> > Sent: Friday, February 06, 2004 2:17 PM
> > To: ORACLE-L_at_fatcity.com; oracle-l_at_freelists.org
> > Subject: Defrag tool on the Oracle database server
> >
> >
> > Hi DBAs,
> >
> > My sysadmin asked me if he can use a tool called
> Diskeeper to defrag the
> > disks on our Windows servers.
> >
> > Did someone know that tool?
> >
> > What could be the impact on the Oracle datafiles?
> >
> > Thank you and have a good week-end ...
> >
> > Luc
> >
> > ---------
> > Luc Demanche
> > AstraZeneca R&D Montreal
> > Oracle Database Administrator
> > 514.832.3200 x2356
> >
> >
>
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Sat Feb 07 2004 - 11:53:47 CST
 |
 |