The Sybase application code and database files will be stored on IBM
ESS (shark) disk units, external to the RS/6000. We access the sharks
over the storage area network.

Each volume group contains disks from both Site 1 and Site 2 sites.
AIX LVM mirroring is used, so each logical volume uses at least one
disk from each site. All the production disks are available to both
the live and disaster recovery servers. The mirroring is real time and
guaranteed that the disks in each site will be the same.

Given this info, please could you comment if Sybase will object to
this for any reason in the following scenarios:

1. Production server has non-disk related failure. DR machine is
brought online with production disks.

2. Production server has complete failure (including disks). DR
machine is brought online with mirrored disks.

Thanks in advance
Tom


Anthony Mandic <d7@hotmail.com> wrote in message news:<3EF037A7.2DCE8C2A@hotmail.com>...
> Thomas Richards wrote:
>
> > The disk mirroring will be across two sites in case of a disaster at
> > the production site. I did not make this clear in my original post -
> > in the event of a complete disaster with the production server, the dr
> > box will be brought online with the mirrored copy of the production
> > server's disks.
>
> OK, what you are describing appears to be HA rather than disk
> mirroring. Sybase's own disk mirroring can't do this across systems.
> So its either something that your RS/6000 can do or its third party
> software. Perhaps some sort of cluster solution.
>
> > Our databases comprise a data warehouse. They are static throughout
> > the day and only change during the overnight batch. The original
> > suggestion for our dr strategy was cold standby ie having the dr box
> > use the prd dumps to restore the databases - however the advantage
> > disk mirroring appears to have is its simplicity.
>
> Yes, with a cold standby its a matter of making dumps and loading
> them. With later versions of ASE, you could quiesce the databases
> and copy the devices. Its not really that much simpler though.
> Note, you could also just load transaction log dumps after the
> overnight batch processing. This would be faster than loading
> full dumps but you still have the same issues of doing the work.
>
> > When you refer to device ids do you mean the physical name of the unix
> > logical volume?
>
> Specifically, its the device name you use with the 'disk init'
> command. Usually, this is a Unix device or filename and path.
> Substituting this for an alias makes it easier to move devices
> like disk arrays around and not worry about any change in
> device names/ids between systems. The alias would just be a
> symbolic link to the real device name.
>
> > Is your comment in reference to swapping disks locally at the
> > production server - would this extend to bringing the dr box online
> > with the mirrored production disks?
>
> I was thinking in terms of moving storage physically between
> two systems. It shouldn't be an issue with storage shared
> between two systems. However, I don't think you are referring
> to this. Another option is to use shared network storage like
> a SAN or NAS solution.
>
> > As we are not a live transactional database we are not concerned with
> > downtime unless it exceeds 12 hours. We are looking for something
> > simple to implement and that would scale to Sybase 12.5 when we go up
> > to that.
>
> OK, in that case you won't have a need for something like
> OpenSwitch.
>
> > Given this, please could you advise if disk mirroring is feasible and
> > if it is a suitable strategy over cold standby?
>
> It is, but you'd need to elaborate a little more. Are you looking
> at doing this mirroring via some sort of software or via hardware?
> It probably doesn't make any difference but I'm not clear on what
> you really consider to be mirroring. If your primary system goes
> down, if you don't have the data copied already or dumps on hand
> your DR system won't be up to date. So you would either need dumps
> made just after the overnight batch processing and taken to the
> other site and loaded or the mirroring to happen in real time.
>
> -am © 2003

Thomas Richards wrote:
>
> The Sybase application code and database files will be stored on IBM
> ESS (shark) disk units, external to the RS/6000. We access the sharks
> over the storage area network.
>
> Each volume group contains disks from both Site 1 and Site 2 sites.
> AIX LVM mirroring is used, so each logical volume uses at least one
> disk from each site. All the production disks are available to both
> the live and disaster recovery servers. The mirroring is real time and
> guaranteed that the disks in each site will be the same.
>
> Given this info, please could you comment if Sybase will object to
> this for any reason in the following scenarios:
>
> 1. Production server has non-disk related failure. DR machine is
> brought online with production disks.
>
> 2. Production server has complete failure (including disks). DR
> machine is brought online with mirrored disks.

From your description, it looks fine. Since the storage is
external and accessible from any machine, any machine should
be able to run the ASE server. Any machine capable of running
it should have sufficient memory and shared memory configured.
It would then be able to launch the dataserver process and find
everything (I am assuming that the physical device/volume names
you've used within ASE with the 'disk init' command would match
on any machine. This should be the case unless AIX's LVM uses
unique volume names for the same shared volumes. This would be
easy to check though).

After a failure you may need to clear the ASE server's krg file
(it creates this on server start and holds its process id and
shared memory id etc.). It uses the krg file to prevent another
instance of the same server starting on the same machine.

The simplest test to see whether it will run or not is to shutdown
the production ASE server and restart it on the DR system. Observe
the ASE error log as it starts up. If it activates all its devices
snd reports no errors, it would be safe to assume that it works. If
not, work out what the problem is. The production side shouldn't be
affected by this test so you should be able to start it again after
stopping the DR side (however, it won't hurt to make backups first).

-am © 2003