IDS Forum

RE: consistency check on offline database

Posted By: Sebastian, Norma J.
Date: Friday, 5 January 2007, at 12:33 p.m.

In Response To: AW: consistency check on offline database (Andreas.KUTSCHE@spar.at)

Hi Andreas,

What's your version of IDS?

I believe (others will need to respond/verify) that newer versions of
oncheck will not lock tables?.... (sure would be nice if that is
true). therefore, you could run it slowly in production without harm.

Andreas, settle in for a long read.... (sorry)....

I think our setup is much broader than yours although your DB is much
bigger. This makes it easier for me to run onchecks on 'near
production' data. And in a pinch, I can get agreement to run limited
onchecks on production. (i.e. find an issue on one table on a test
system or hotsite, and then that's the only table I need to hit in
production instead of doing them all).

We have an EMC BCV on our production database, and one at our hotsite.
We have EMC SRDF running from the R1s (the production database disks) to
the R2s (hotsite). Because the hotsite has its own BCV, when we want
the hotsite up for testing or projects, we sync the hotsite BCV to the
hotsite R2, then split the hotsite BCV and bring it up as the hotsite
database. This gives us a working system at the hotsite AND we are
still keeping the SRDF from production R1 disks to the hotsite R2 disks.

>> There's a BCV on the main site (maybe it would be better to locate it
on the

>> failover site?) which is synchronized once every day. That would be
our candidate for

>> consistency checks.

it is something you could think about. We have them on both ends (PRD
and hotsite) so not an issue for me.

Yes, as you said, my multiple BCVs and systems enable me to do onchecks
on near-production data images without compromising my ability to do a
PRD BCV split and have that quick restore image ready.

>> If the system runs on new disks (or the disks are initialied with
zeroes)

>> unused space in the database doesn't use much space on the tape
because it

>> gets compressed automatically.

Hmmmm.... we didn't think of that, and I guess our Symantec/Veritas
Netbackup setup is pretty solid so we didn't put too much thought into
raw backups from BCV. Although, that is my goal on our Oracle system so
thanks for that info.

>>Do you run your onbar backups on the production system?

Yes. We are IDS 9.4 on Sun Solaris (64 bit all around). We use
Symantec/Veritas Netbackup as the partner for onbar. My onconfig is set
to run 12 backup threads, I have 128 dbspaces to backup with those 12
threads. Our backup runs from 4AM to approx 8AM daily. We redesigned
our Netbackup setup and this important backup goes to disk not tape.....
it used to take 8 hours for the backup, but going to disk, we're down to
4 hours.

Restores of the onbar backups take about 6 or more hours. So yes, the
BCV is a much quicker fall-back, but 6 hours isn't so bad either.

It all depends where you want / can afford to invest in your
infrastructure.

>>Do you run a full backup every day?

Yes. Level 0 every day. The pressure to change to a different strategy
with level 1s and 2s has never been strong for us, so level 0 ever since
I remember (year 2000).

>>Doesn't that hurt your performance?

Yes, it impacts. But here's another reason we're probably different.
We have SAP. We have a central database instance, a central SAP
instance, and multiple application servers. The central DB instance and
the central SAP instance are on the same Solaris box at this time. The
users and batch jobs running through SAP are load balanced via SAP
amongst the SAP central instance and application servers (this includes
2 SAP batch servers). Because the SAP processing between the hours of
4-8AM is light on our system, it is ok to pummel the central DB
instance/Solaris server with the IDS onbar backup. Matter of fact,
monitoring it with a vmstat.... the CPUs on this DB server have 0% idle
CPU during the backup.

Meanwhile, the SAP central instance memory holds a lot of data, and
shares that out with the SAP memory on the application and batch
servers. Our batch processing is pretty much finished by 4AM, and our
users have not yet started with heavy usage.

Acutally what could hurt our performance more is the SRDF. When SRDF is
running, I have double-digit checkpoints on the database. However with
a pile of SAP application memory/cache (6gb I think) and a pile of
informix memory/cache (currently at 8gb), and a pile of EMC disk
cache..... we're cache rich.... and the users don't notice the
double-digit checkpoints. (long checkpoints are bad only if the users
feel the pain).

Hope this info is helpful.

If you have read this far and still would like more.... you could mail
me directly at normajean.sebastian@tellabs.xxx (replace xxx with com)

Norma Jean Sebastian

ERP Support Administration

IT - Enterprise Technical Services

-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Andreas.KUTSCHE@spar.at
Sent: Thursday, January 04, 2007 1:03 PM
To: ids@iiug.org
Subject: AW: consistency check on offline database [8116]

Hello,

we have two big production systems with about 5 TB each (running on HPUX

IA64/Montecito and HP Surestore/XPsomethings), therefore the number of
copies

is quite small.

We have one test system built from a Continous Access (SRDF) copy at a
......

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

Messages In This Thread

• consistency check on offline database
  Andreas.KUTSCHE@spar.at -- Thursday, 4 January 2007, at 7:28 a.m.
  • Re: consistency check on offline database
    Keith Simmons -- Thursday, 4 January 2007, at 9:21 a.m.
    • AW: consistency check on offline database
      Andreas.KUTSCHE@spar.at -- Thursday, 4 January 2007, at 9:56 a.m.
  • RE: consistency check on offline database
    Sebastian, Norma J. -- Thursday, 4 January 2007, at 12:52 p.m.
    • AW: consistency check on offline database
      Andreas.KUTSCHE@spar.at -- Thursday, 4 January 2007, at 2:03 p.m.
      • RE: consistency check on offline database
        Sebastian, Norma J. -- Friday, 5 January 2007, at 12:33 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.