Re: Cobol .DAT backup solution

Michael Wojcik<mwojcik@xxxxxxxxxxx> 09/20/06 10:30 AM >>>

In article <4n83eqF99t71U1@xxxxxxxxxxxxxx>, "Frank Swarbrick"
<Frank.Swarbrick@xxxxxxxxxxxxxx> writes:
James J. Gavan<jgavandeletethis@xxxxxxx> 09/14/06 4:35 PM >>>

Frank - if you are looking in. How do you handle similar problems with
banking ?

Essentially, we do pretty much what one of your examples was. We have
databases (DL/I) and we have sequential maintenance (transaction) files.
If
our database was to crash and burn during the day we could restore to
beginning of day and re-apply the maintenance files to recover up to
that
point in time. This doesn't allow 24-hour online uptime, exactly,
though.
More like 23.5 or so. There's always a period right before the beginning
of
the new day where we are "down" in order to copy our databases that we
just
updated during nightly processing over to our online databases. We
then,
before bring them up, reapply any maintenance/transactions done since
our
end-of-day cutoff time.

(I haven't been following this discussion closely, so I don't know
if anyone's mentioned this approach yet.)

I knew one customer who implemented a daily backup for an always-up
system using disk mirroring. It worked something like this:

- Online databases and transaction logs on a mirrored filesystem.

- The backup process starts by "breaking the mirror": the storage
manager is told to remove one of the disks from the mirror. It
flushes all pending writes and brings the files into a consistent
state as part of that process, of course.

- The backup is taken from the removed disk. Now they have a backup
of the database at the point where the mirror was broken, plus the
transaction logs up to that point, so they can tell exactly what
logged transactions to apply if they need to roll a backup forward.

- The removed disk is added back to the mirror. The storage manager
resyncs it with the current disks in the background as processing
continues.

If the storage manager is separate from the machine that's actually
doing the transaction processing - typical in large systems with
network-attached storage, for example - then the online system never
even notices the backup is in progress.

And, of course, mirroring the filesystem means you're protected
against some kinds of disk failure. (Ideally you want at least
three copies, so while one copy is out being backed up, you still
have at least two current copies.)

This sounds quite workable, for the most part. The thing that I just can't
figure out is how to integrate "batch" updates into a database that also has
"online" updates; with little or no downtime. As we have it now, while our
online system is down we reapply the online updates that have occured since
the batch processing deadline into our "beginning of day" batch data. We
then copy that database back to the online database and come back online.
Essentially. The online updates since cutoff is fairly minimal, so this
does not take that long. If we were to somehow "roll forward" all of our
batch updates into our online system I imagine that would take quite a
while. Not to mention some records would be as of the new business day and
some would be as of the previous business day, until such time as the "roll
forward" was complete. So I don't think(!) that this is the way to go.

Is something like the following perhaps possible?
- Two online "mirrored" databases, both online most of the time. Call them
Primary and Secondary
- At batch cutoff time disconnect Secondary
- Backup Secondary to a backup database *and* to a "batch" database. (or
use the backup to update the "batch" database after the next step)
- Reconnect Secondary and roll forward all updates that occured on the
primary mirror since the Secondary was detached.
- Do batch processing, using the backup to restore the "batch" database if
necessary because of a program crash or whatever.
- Back up the "batch" database (to a different backup database?)
- Disconnect Secondary
- Copy the batch database to Secondary
- Now here's where I get a bit lost...
- Roll forward to Secondary all updates that occured since batch cutoff the
previous night
- When the previous step is done, disconnect Primary and connect secondary
(all at the same exact time???)
- We're now on the new business day
- Copy Secondary to Primary
- Connect Primary

Yikes. Any comments? Does anyone actually do this 24/7 thing? :-) I
want my silver bullet!

Frank




---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
.

Relevant Pages

  • Re: Information store question from Exchange dummie
    ... Online maintenance should not typically be very hard on the server. ... >> Mailbox Store on the Database tab, ... >> Category: Online Defragmentation ... >> defragmentation has certain disk space requirements. ...
    (microsoft.public.exchange2000.information.store)
  • ms-access 2007 online? How can users log on to access 2007 from the internet?
    ... with SQL Server Express running on ... FTP to the Access database that is now online. ... What software do I need and how can i put it online? ... Also, Microsoft has a free upgrade, downloadable from their web site, ...
    (comp.databases.ms-access)
  • Re: Linux Hardware Quality Labs (was: Linux in a binary world... a doomsday scenario)
    ... > A good exhaustive online centralised hardware database, ... will have influence with or without a logo. ... online database does not help you much: ...
    (Linux-Kernel)
  • Re: Off-line defragmenting
    ... Basically, when data is deleted from Exchange database, deleted pages are ... marked free for usage during the online maintenance of the database. ... An offline defrag is required to recover the white space on the database. ...
    (microsoft.public.exchange.admin)
  • Re: Connecting Access Database to Front Page
    ... Do you want to have an online database? ... if you want to go online you must make use of a web hosting service. ... etc You can set up forms that will show query results. ...
    (microsoft.public.frontpage.client)