object level backup

[unknown]

Where can I find information for ASE 15.0 on object-level
restoration? Is this possible in ASE15.0 now?

[Mark A. Parsons]

I don't recall anything in ASE 15.0.x explicitly described as object-level recovery.

One option that's been around since 12.5.2 (or was it 12.5.3) is the archive database feature. This feature allows you
to mount a database dump such that it looks like a read-only database to the dataserver.

Space requirements in the dataserver are typically miniscule compared to the space that would be required to load the
database dump into a real/fullsize database.

Once the archive database has been mounted you can use normal SQL to 'recover' any objects you want from the dump file(s).

Obviously (?) performance for pulling data from the archive database will be a bit slower than pulling data from a
regular database.

Post by unknown
Where can I find information for ASE 15.0 on object-level
restoration? Is this possible in ASE15.0 now?

[Derek Asirvadem]

We need to keep in mind that a database is a single recovery unit by
definition. There is no object-level backup/restore,and there would be
serious integrity problems if such were provided, so do not look for
it. But there are facilities that can be used.

Some of us have been providing object level backup and restoration for
large tables for years (before the Archive Database Feature, which is
good, but it is a different thing). As a part of the backup regime,
bcp-out said tables; use -F etc to constrain rows; use a view to
constrain currency (if you have a database with Optimistic Locking,
last-updated timestamps, you can extract just the rows that have
changed). You need to quiesce the activity (I was doing it before the
advent of Quiesce command, I have not changed and tested my code with
that), and execute the backup in the correct order of tables. How/what
you restore depends on what diffs you find, which usually means loading
the restore into another Db, so that you can compare the sets of rows
easily via SQL.

If this becomes a regular or structured activity, you can look into
splitting the Db. Eg. Reference and large unchanging tables in one DB;
transaction tables in another (with full DRI).

SQL BackTrack is a 3rd party product that provides the object-level
backup/restore facility, but very few people used it.