Kim Black writes:
> There are several ways to backup an Oracle database. A common method is to
> do a cold backup, requiring all users off the system and the database shut
> down. Its faster and more reliable.
>
> To provide incremental backups, the transactions can be exported and then
> an OS backup can be done on the exported files.
>
> There are ways of performing backups while the database is live, but they
> can be less reliable.
> The Oracle db has to be setup to detect if a transaction wasn't backed up
> and then augment the backup when the transaction is completed.
Thanks, Kim, you obviously know a lot more about Oracle than most
of us. I suspect most people don't quite comprehend the risks and
difficulties involved in doing a hot backup of a big database system.
I don't know as much about Oracle specifically, but I used to write
system admin manuals for a unix RDBMS software company (Unidata), so
maybe I can clarify the nuances a bit.
Remember, we're talking about some pretty major scaling issues.
These are databases designed to scale to, for example, keep
information about tens of millions of customers (even if your website
is much smaller). It's not simply a matter of taking a snapshot of
the data and writing it to a backup device.
For one thing, the data is almost certainly going to be both in
memory and on disk. Even if the database were small enough and the
RAM large enough to keep it all in memory, writing the data to disk
for any significantly large database would suck up a lot of system
resources and slow system performance toa crawl for a large chunk of
time.
Which brings us to the question of what happens to those
transactions that are coming in while the database is being copied,
since, while we would hope the transactions themselves are atomic (*),
we can't assume that they'll remain atomic once they enter the db
system. Then we'd have tables that are slightly different in time and
hence in contents.
(* Atomic**, i.e. each transaction is kept as an encapsulated set of
operations that cannot be interruped midway through. The classic
example is a transfer of funds from one account to another - the
"transfer" is really two operations, one to decrease the amount in
the first account and another to increase the amount in the second
account).
(** Atomicity is one part of the ACID test for transactional databases,
ACID being an acronym for each of the four qualities required, which
I can't remember the other three of at the moment and now it's time
for me to go home :-).
Most large scale systems that provide to backup capability
provide a combination of normal backup and some sort of system which
keeps track of the incoming transactions while making the backup, then
applies them to the backuped up version of the data, as Kim describes
above. Since most databases of this magnitude are not exactly running
on machines with scads of excess capacity, there's still a significant
performance impact.
All of the above is why live backups are non-trivial.
Steven J. Owens
[EMAIL PROTECTED]
____________________________________________________________________
--------------------------------------------------------------------
Join The NEW Web Consultants Association FORUMS and CHAT:
Register Today at: http://just4u.com/forums/
Web Consultants Web Site : http://just4u.com/webconsultants
Give the Gift of Life This Year...
Just4U Stop Smoking Support forum - helping smokers for
over three years-tell a friend: http://just4u.com/forums/
To get 500 Banner Ads for FREE
go to http://www.linkbuddies.com/start.go?id=111261
---------------------------------------------------------------------
