[an error occurred while processing this directive]

HP OpenVMS Systems

ask the wizard
Content starts here

Online Disk Volume Archiving, Cache Control?

» close window

The Question is:

 
We have a third-party storage area network and disk server.  Due to the long
 distance between our primary and backup sites, we have to take snapshots of
 disk-resident data rather than use continuous updating or shadowing methods.
 At a specific, predictab
le, repeatable time of day we need to stop system activity, take our disk
 snapshots, and then resume activity.
 
During this snapshot time, we need to force an MPW flush in order to assure
 that the disks are internally self-consistent with respect to all applications
 data, directory, index-file, and bitmap structures.  While a brief dismount &
 remount sequence of ea
ch disk would force the issue, we would prefer to avoid something that is
 subject to such issues as I/O rundown if a user or late-running ad-hoc batch
 job happens to be on one of those disks.  Forcing an MPW flush without a
 dismount would be an ideal solu
tion.
 
Is there a way that we can accomplish this flush that does not involve
 mount/dismount activities?  For instance, is there a system internal routine
 we could call that would force a total MPW flush?  (And can it be called from
 Ada or Basic?  If a routine e
xists but is not callable from those languages, can you suggest Alpha Macro
 code that would call the MPW routine and that could itself be called from an
 Ada or Basic context?)
 
 


The Answer is :

 
  The dismount is the only available supported mechanism for flushing
  all OpenVMS disk caches out to backing storage.
 
  An additional issue here is less the OpenVMS caches, but the various
  application contexts.  Should an application cache its data in local
  memory, it may or may not have consistent data stored on the disk.
 
  Various database packages can provide mechanisms for on-line BACKUP,
  of course.
 
  Related online BACKUP discussions include (1092), (2467), (2512),
  (2760), (3147), (5762), and likely others.
 

answer written or last revised on ( 3-FEB-2003 )

» close window