| Well, although Rdb/VMS does not have restore by area, VAX DBMS does.
They achieve this by *requiring* the use of the AIJ to roll forward
any changes to that area.
I would suspect that Oracle must have to have something similar.
Check this conference a few notes back on some Oracle V6 info.
regards,
Kevin
P.S. I assume this is for ComputAsia?
|
| According to the information that I have from Oracle's "international user
conference special education courses" (Oct 1-2, 1987).
An Oracle database comprises one or more 'TABLESPACES', each of which
is one or more VMS files.
A 'TABLESPACE' is the unit of recovery from media failure.
It is the unit of space for relations and indexes.
The rollback file is also part of the tablespace (analogous to Oracle V5
before-image files)
{I will use the term 'relation' to avoid confusion with 'tablespace'}
It appears that relations cannot span tablespaces.
Indexes can be in a different tablespace than the base relation.
After Oracle makes the appropriate marks in the tablespace, you, the DBA,
can use VMS backup to backup the tablespace.
Use of the AFTER IMAGE JOURNAL is required for media failure protection.
This means that the user has to pay the cost of using the AIJ. This is not
the case with Rdb.
To recover a database or tablespace:
use 'RECOVER DATABASE' or 'RECOVER TABLESPACE'
using the Redo Log, SQL*DBA (their RMU equiv) rolls forward changes
since the last checkpoint prior to the backup of the tablespace.
A checkpoint in Oracle is a point in time when all dirty pages in the
database which are stored in memory have been written to the disk.
WHAT DOES THIS ALL MEAN:
Your customer's concern is that they will need to restore the entire
database if a single page from a single relation goes bad (gets corrupted).
Oracle has promised that they can restore just that relation.
One issue is why the relation would become corrupted:
1) If it is media failure (disk failure), volume shadowing or using VAXsimPlus
might be a better solution. VAXsimPlus is free with a service contract on
Digital disks. It predicts disk failure, notifies the system administrator,
and makes a volume set with a spare disk. This allows one spare disk to
act as a volume set for many regular disks. It is a low cost way of getting
very high disk reliability. The volume shadowing is more expensive but
will also do the trick.
These techniques are the best way to avoid corruption due to media failure.
2) If corruption, however, is due to a bug in the database software, then
it is not clear the rollforward with an AIJ is the answer. The problem
probably goes beyond a single relation or tablespace and would require
a more complete database restore. The problem is that indexes and
other relations related to the corrupt relation might need fixing but
might be in a different tablespace.
3) The third, and most likely, problem is that the user has entered
inconsistent data. While the relations are all readable, the data is
inconsistent. With Rdb's referential integrity, this problem is minimized
because rules control database consistency. Oracle doesn't have referential
integrity and relies upon applications and users to maintain consistency
(which caused the problem in the first place).
In this case, the user will want to use an old backup and start again. They
don't want to rollforward to the current state. Oracle's backup technique
doesn't allow this at all.
To get this functionality, Oracle would require you to take the database
offline and use VMS backup to make a copy. Then, on recovery, you could
restore the database as of the time of the backup.
Rdb allows this functionality while keeping the database online and using
incremental backups too.
Other issues:
Oracle uses VMS backup while the database is active. By playing with timestamps
they hope that on recovery they can figure out what changes were made to
each page as it was being backed up. That is, they need to sort through
the backup and selectively apply the AIJ.
I would question the reliability of this technique. Many customers use
backup because the question AIJ accuracty (at least they do with INGRES).
A mixture of online VMS and AIJ backup with Oracle acting as judge is
scary. What they are doing is very complex. The bugs are probably
not shaken out.
In contrast, Rdb uses its own backup facility. One that is designed to
work with the database. It is much faster than VMS backup and allows the
use of multiple tape drives to backup a database concurrently.
Another question is what happens if a user is making changes to one
part of the database (tablespace A) as the DBA is recovering another part
(tablespace B). Is consistency maintained between the tablespaces?
Does all activity in the database stop?
I hope this helps.
-- David Dreyfus
381-2893
|
|
> Well, although Rdb/VMS does not have restore by area, VAX DBMS does.
> They achieve this by *requiring* the use of the AIJ to roll forward
> any changes to that area.
More importantly the rollforward application keeps a watchful eye over
the entire RECOVER operation to insure that the "transaction level" of
the entire database is maintained...when I just perform a RESTORE of
an individual area the area can not be used (since it is a period of
time "behind" that of the other areas in the database environment).
If it was allowed to be used 'physical pointers' between areas such as
in index that is stored outside of the restored area that points into
the area would result in bugchecks because it would be left
inconsistent. The other problem would be in logical relationships
(an line items in one area are stored with corresponding order records
in another file) these are maintained by constraints. If a straight
restore was performed these logical inconsistencies would result in
constraint violations.
Thus when an area is restored it is marked inconsistent and then
during the recovery of the individual area all the recovery switches
(such as UNTIL=) can be used. The recovery algorithms insure that all
areas are the same transaction level and thus physically as well as
logically consistent before they can be used.
Although Rdb/VMS does not currently have this capability, it was
designed and implemented in KODA for our own product portable
features and it is high on the wish list for large database support.
> I would suspect that Oracle must have to have something similar.
> Check this conference a few notes back on some Oracle V6 info.
If they don't then there is a good chance for inconsistencies to
develop. If, as stated in the previous reply, a tablespace is the
unit of recovery I would find it hard to believe that they have
implemented an equivalent facility.
|
| During my benchmark last week in LAX, the customer and I discovered
that we had 31 index extents and were projecting a total of over
300 for the final step in the benchmark. At 2:30 in the morning,
we decided to reallocate the index "space definition" for a single
table of 342,000 rows. Here's what was required (Oracle 5.1.22):
=> Shutdown the database was required.
=> Use Oracle EXPORT utility to export the table (1 hour)
=> Drop the table including all definitions, space parameters, etc.
=> Recreate (by hand) the table defn, NEW space parameters, index
defns (5) eetc.
=> IMPORT the table with INGORE=Y to bypass ALL warnings (1.5 hrs)
=> export the ENTIRE database to get all partitons and tables into
a backup form in a known condition (another hour)
=> Warm start Oracle
=> Resume benchmark (6:30 AM and many cups of coffee later)
Now, this table happened to be on a single Oracle partition directed
to a single physical file with NO OTHER tables involved. You can
imagine what the problems would have been if the index was located
in another partition (on another disk) which contained other tables.
In addition to the fragmentation of the database partition files,
you've got to revisit your space allocation for the other tables
and all that crap.
Your best bet with this customer is to describe in intricate detail
the exact steps you would use to recover data with Rdb. Then encourage
your customer to ask the same questions of Oracle .... that should
do the trick.
Gerry "Sleepy" Duncan
|
| You also might want to consider an Rdb/VMS non-disclosure presentation
for your customer. After all, are they really going to have a 10GB
database next week, next month, or next year?
|