Database Reference
In-Depth Information
EODA@ORA12CR1> create temporary tablespace temp_huge
2 tempfile '/tmp/temp_huge_not_sparse.dbf' reuse;
Tablespace created.
After copying the sparse 2GB file to
/tmp/temp_huge_not_sparse.dbf
and creating the temporary tablespace
using that temp file with the
REUSE
option, we are assured that temp file has allocated all of its file system space and
our database actually has 2GB of temporary space to work with.
■
in my experience, Windows NtFs does not do sparse files, and this applies to UNiX/linux variants. On the plus
side, if you have to create a 15GB temporary tablespace on UNiX/linux and have temp file support, you'll find it happens
very fast (instantaneously); just make sure you have 15GB free and reserve it in your mind.
Note
Control Files
Control files are fairly small files (they can grow up to 64MB or so in extreme cases) that contain a directory of the
other files Oracle needs. The parameter file tells the instance where the control files are, and the control files tell the
instance where the database and online redo log files are.
The control files also tell Oracle other things, such as information about checkpoints that have taken place,
the name of the database (which should match the
db_name
parameter in the parameter file), the timestamp of
the database as it was created, an archive redo log history (this can make a control file large in some cases), RMAN
information, and so on.
Control files should be multiplexed either by hardware (RAID) or by Oracle when RAID or mirroring is not
available. More than one copy should exist, and the copies should be stored on separate disks to avoid losing them in
case you have a disk failure. It is not fatal to lose your control files—it just makes recovery that much harder.
Control files are something a developer will probably never have to actually deal with. To a DBA, they are an
important part of the database, but to a software developer they are not really relevant.
Redo Log Files
Redo log files are crucial to the Oracle database. These are the transaction logs for the database. They are generally
used only for recovery purposes, but they can be used for the following as well:
•
Instance recovery after a system crash
•
Media recovery after a data file restore from backup
•
Standby database processing
•
Input into “Streams,” or Golden Gate - redo log mining processes for information sharing
(a fancy way of saying replication)
•
Allow administrators to inspect historical database transactions through the Oracle LogMiner
utility
Their main purpose in life is to be used in the event of an instance or media failure, or as a method of maintaining
a standby database for failover. If the power goes off on your database machine, causing an instance failure, Oracle
will use the online redo logs to restore the system to exactly the point it was at immediately prior to the power outage.
If your disk drive containing your data file fails permanently, Oracle will use archived redo logs, as well as online redo
logs, to recover a backup of that drive to the correct point in time. Additionally, if you “accidentally” drop a table or
