Re: Hot backups vs. Offline Backups

From: Mick Shadduck <shadduck_at_stbernard.com>
Date: 1995/12/18
Message-ID: <30D5ED6B.5B2D_at_stbernard.com>


>>jklaren_at_qualcomm.com (Jon Klaren) wrote:
>>You may want to consider just a good application to work with your
>>backup system to have a complete backup. If your system is like ours,
>>shutting down the database is more problematic than the time it takes
>>to mirror or backup the server. One package that I understand is on
>>the market is St. Bernard's Open File Manager. It apparently works
>>with all backup systems from ArcServe to Colorado, and will allow them
>>to backup Oracle or any other file system even if there are users
>>logged in and making changes to the files. We are going to be getting
>>an evaluation copy inhouse and see how it works? You can contact them
>>at www.stbernard.com or on compuserve at GO STBERNARD.
>Russell McDonald wrote:
> I thought there was more to the issue than just whether users were
> accessing the files. Unless the database has been shut down normally
> (you can include shutdown immediate in this defintion if you want,
> many people would not) the database files will not be in a consistent
> state - ie some parts of a transaction may have been written to disk
> and other parts still be cached waiting writeback.
>
> Is anybody prepared to comment or have experience with the product.

First, Open File Manager (OFM) has been tested heavily with Oracle, and in fact, St. Bernard Software is a participant in the Oracle Business Alliance Programme (BAP).

With OFM installed, using your existing backup (ARCserve in this case), it is not necessary to shutdown the database in order to back it up--even if modifications are being made to the database. Here's why...

To ensure that the backup program receives a static copy of the file, a pre-image cache (in the form of a standard disk file) is dynamically allocated. When a file is opened for backup, any file write operation from another application causes a copy of the data that will be overwritten to be placed in the pre-image cache. If read requests from the backup application are first satisfied from the pre-image cache, the file appears entirely static to the backup application, while it is in fact modified and seen normally by other applications.

As soon as the backup application closes the file, having backed it up, the pre-image data can be discarded. Since the amount of data that actually changes is generally small in relation to the file size, and because only one file is typically being backed up, the amount of pre-image data is insignificant. System performance is only affected for access to the file currently being backed up, and in practice is unnoticeable.

The final technique is to ensure that a file is in a good state at the time access to it is allowed for backup. This is achieved by monitoring TTS (if used) in combination with file write activity. If a file uses TTS either explicitly or implicitly, its current transactional status is determined, otherwise the elapsed time since the last write operation is used to determine transaction breaks. In practice this is a very reliable method, since very few applications spread write activity for a single transaction because of the risk of power failure. A third mechanism is provided to allow an external application to 'register' to provide transaction status. Open File Manager then automatically calls the registering application to obtain status when its files are about to be backed up. Using proprietary techniques, Open File Manager can hold file open requests from the backup application indefinitely without any detrimental effect, although typically the delay is only a fraction of a second, and goes entirely unnoticed.

For more information--white paper, press releases, corporate background and a 15-day fully functional live trial--contact St. Bernard's home page at http://www.stbernard.com


 Mick Shadduck, MIS Manager       | mailto:shadduck_at_stbernard.com
 St. Bernard Software             | http://www.stbernard.com
 15175 Innovation Drive           | ftp://ftp.stbernard.com
 San Diego, CA 92128  USA         |----------------------------------
 619.676.2277 x3011               | CIS: 72420,1611
 619.676.2299 FAX                 |      GO STBERNARD
---------------------------------------------------------------------
Received on Mon Dec 18 1995 - 00:00:00 CET

Original text of this message