| >> Given that ORACLE Version 6.0 has online backup
You are being generous with the term "online". In order to achieve "online"
backup, you must turn on archiving which is similar to our AIJ. (We do online
backup via the SNP function and time stamps on the data pages.)
You do realize that Oracle online backup is really VMS backup ... don't you ?
.... that's what I thought. Here's how it works. (I probably won't get the
syntax correct but you'll get the idea.)
1. DBA logs on to VMS priviledged. Note that this account usually has
CMKRNL and BYPASS.
2. He/she starts SQL*DBA and connects to their database of choice.
3. Then the ALTER TABLESPACE tablespace_name BEGIN BACKUP. (Tablespaces
are similar to Rdb's storage areas.) Note that this command
does absolutely nothing in terms of starting a disk/tape backup.
It simply signals to the LGWR (redo log writer) to make a
special entry to the current redo log that a backup is going
to be started soon. (Like whenever the DBA/computer operator
types in the commands or runs the .COM files.)
From this point forward, the LGWR writes additional information
to the redo log in order to keep track of data that is commited
during the backup. Also note that the data pages within the
tablespace also continue to get updated just as though nothing
had ever happened.
If you forget to issue the BEGIN BACKUP command and the database
shutsdown in a not normal way, then the tablespaces' files may
be backed up incorrectly and you will not be able to use these
backup files for recovery (per Oracle DBA manual pg 15-24).
4. A VMS backup is started (with /IGNORE=INTERLOCK) to start the backup
of the tablespace. You can also use DCL COPY which is what
my customer does on his DEDICATED 8550 for just Oracle backups !!
5. When your VMS backup or DCL COPY is finished, you MUST REMEMBER
to connect to the database again and issue this command:
(nothing automatic here .... just think of how easy this is
to remember by your minimum wage midnight-7am computer operator)
ALTER TABLESPACE tablespace_name END BACKUP.
If you forget to enter the END BACKUP command and the system
continue to run. At the next database startup, the Oracle
RDBMS will assume that media recovery is necessary, and MAY
require the use of offline redo logs (per Oracle DBA guide
pg 15-24). .... EVEN THOUGH your backup finshed HOURS ago
AND you've already sent your tapes offsite !!
6. Now, this is only for a given tablespace. If you wanted to provide
online backup like Rdb has, the DBA would specifically have to
issued the ALTER TABLESPACE command for EVERY TABLESPACE within
the stinking database. Then start a VMS backup job for EVERY
physical file within each tablespace. (How many 9000's,
KDM70, and TA90's would you like Mr. Customer .... oh, you can do
this on your Sequent ? ... un huh, right.)
The DBA would be unable to know for sure which tablespaces had been
modified since the last offline backup because Oracle doesn't appear
to have data structures on the data pages nor an incremental,
self-contained backup utility. Now that is real vision !!
>> Given that ORACLE multiversioning uses the redo log and may lose
>> old versions of records,
Actually, rollback segments are used too. Depending on the application
and whether or not the online backup is running, the redo logs may never
be read during a read consistency transaction.
I've studied this at length and it's not clear to me that you would lose
records but you certainly have a good chance of losing the old versions.
In fact, this has happened many times to my good (but still stupid) customer.
Read consistency is a VERY serious problem for Oracle but to be honest,
unless the applcation is using batch processing or is simply written
poorly, it is probably too early in the game for this to surface through
the trade rags. I can tell you this, as more and more customers install
Oracle V6 with large production batch jobs, this is going to get very hot.
I wish there was some way we could design a benchmark that would expose this
severe weakness.
Let me give you an example. My customer has batch jobs that run for
HOURS. One job in particular starts by reading a ton of records (read_only
transaction). Then the program goes off and does backflips for a couple
of hours analyzing the data, reading other tables, printing reports,
creating sequential files, etc. During this time, other programs are
updating the selected data records like crazy. Oracle recognizes that
a read_only txn is active and begins writing additional records like
crazy to the rollback segments. (It has to do this because the updaters
have already written to the database pages.)
So, finally, the read_only program decides it is time to re-read the original
records. (Remember, still in the same transaction.) Oracle sees this and
realizes that, holy cow, this guy wants THOSE OLD records AGAIN and begins
plowing through the rollback segments in an attempt to reconstruct (that's
right) the original records using time stamps. If Oracle cannot find the
records in the rollback segments to satisfy the reconstruction process, the
program abends with "ORA-1555 snapshot too old (rollback segment too small)"
(per Oracle DBA manual, pg 12-4). (Sooooo, you want to know why Oracle V6 is
SOOOOO cpu and dio intensive ..... think about this for a while !!!)
According to the Oracle documentation, the work around is to increase
the size and/or number of rollback segments OR re-start the transaction,
neither of which will help the failed program.
>> is ORACLE Version 6.0 online backup prone to failure?
You bet it is !!! More importantly, it is prone to human
mistake, is too labor intensive, and has too many pieces to
manage. In addition, the constant shifting of tablespaces
on/offline, redo log switches, rollback segment switches, etc.
make it virtually impossible to develop a plan to balance you
dio load. Imagine what this would be like with several databases
active with hundreds of tablespaces. To make matters worse (and
better for Rdb) they have nothing that even approaches DECtrace
and RdbExpert which is the precise place where we are going to
kick some butt ! My little customer (gross revenues of less than
$110m) with about 5-7gb of data has, at last count, 6 dbas and they
are stretched very thin.
Hope this helps and I appologize for the ramble. If you need clarification,
put another note here or send me Email.
-- gerry
|
| >> You specified a number of steps required to backup an Oracle database
>> or part thereof. They are obviously tedious and prone to error.
>> However, couldn't you put all of the ORACLE and VMS BACKUP commands
>> into a command procedure (.COM) and run it just as any other job?
Absolutely and, in fact, this is what my customer does. The
point I wanted to make is that the DBA must know the names and
locations of these physical files as well as the Oracle names of
the tablespaces. One thing I forgot to mention is that a tablespace
can consist of multiple physical files on different disks. So
let's assume that the DBA decides to add another physical file to
a tablespace (because the original tablespace filled up and the database
shutdown). The Oracle part is relatively easy. However, he must
manually edit his .COM files, and add the VMS backup of the new
physical file and needs to document his recovery procedure for
restoring the new physical file, etc. If he is trying to execute
multiple backup jobs at the same time to expedite the process, he
must decide which batch que and/or how many backups to spawn at the
same time. And the list of issues goes on and on.
>> The reason I ask is that if we are going to sell this as an Oracle
>> weakness, we need to understand just what is and not possible for them
>> to do.
I agree completely. This is not to say we don't have our weaknesses.
Oracle's online backup, in my opinion, places a heavier load on the
CPU (crc emulatio & VMS 5.3 backup), i/o interfaces (especially CI),
and the disk drives. Hopefully, the Rdb folks can comment on the
load Rdb's backup takes.
The point I usually try to make is that there is less risk with Rdb's
backup strategy and that we have a cleaner approach. You do have to
be carefull when you challenge Oracle's approach. Hopefully, these
will allow you to pre-load the customers so they ask the right
questions.
|
| The Rdb/VMS RMU/BACKUP approach was specifically chosen to reduce the odds of
operator error in performing backups. We had originally hoped to include a
subset of the multi-file database support in V2.3, but determined that
relying on VMS BACKUP to correctly backup the possible multitude of files
spread far and wide over a disk farm was too unreliable. Instead, we
delayed all multi-file support until we could write a high-performance
*database* backup utility.
Someone current on the matter would have to comment on RMU/BACKUP vs VMS BACKUP
resource utilization as I have no knowledge of current performance comparisons.
However, RMU/BACKUP has numerous features to speed throughput for complex
backup cases.
- It optimizes tape speed, something VMS BACKUP has trouble with. VMS BACKUP
takes data off of one disk and writes it to one tape. You can run multiple
copies of VMS BACKUP to get multiple parallel streams, but EACH STREAM
IS RUNNING SUB-OPTIMALLY. If the disk is busy doing other work or is
otherwise unable to supply data at full speed, then the tape is *not* going
to be writing at its full capability. Consider an on-line backup to a
TA90 under the ORACLE approach. The high performance tape drive will be
sitting around most of the time waiting for VMS BACKUP to get data off of the
busy disk. Contrast this with RMU/BACKUP which will pull data off multiple
disks simultaenously and feed the data to the TA90 as fast as it can take the
data. On a pure competitive level: You need more tape drives to back up
an ORACLE system in the same timeframe as you can an Rdb/VMS system.
- Databases are typically preallocated for performance reasons and generally
have from 30-50% of their allocated space unused. With ORACLE's use of VMS
BACKUP, then entire database file must be backed up, leading to
additional tape I/O (more tapes, longer backup times). RMU/BACKUP
does not need to copy the unallocated pages to the backup tape, potentially
saving many hours of backup time and many tapes.
- RMU/BACKUP supports incremental backups (including on-line), further
reducing the amount of data which must be written to tape and speeding
the backup operation.
- RMU/BACKUP goes further in reducing unnecessary CPU costs than does VMS BACKUP.
For example, on 6250BPI and more modern tape drives, the media is already
protected by hardware CRC in the drives. However, there are end-to-end
error conditions that can still occur, thus making a software error check
highly desirable. RMU/BACKUP can provide the full CRC used by VMS BACKUP, or
a less costly end-to-end check for hardware environments such as TA90s.
Hal
|