ADSM-L

64 bit Oracle issue resolved; audit volume issues

2004-03-25 10:39:51
Subject: 64 bit Oracle issue resolved; audit volume issues
From: "Jolliff, Dale" <xjolliff AT TI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 25 Mar 2004 09:39:24 -0600
Thanks to all who responded and reminded me about the location of the
dsm.sys file for the 64bit Oracle agent.  I just couldn't remember.
Senility is... um,  ... rough.

On another unrelated issue, I had the infamous ANR2209W on a copy pool
volume - I audited it and got this message back - I don't recall ever
seeing this before.  I searched the FAQ and didn't get any hits on the
string "NumEmptyVols", and I see a lot of questions on ADSM.org, but not
many answers.  Is it time to audit the DB?


03/25/04   08:28:22      ANR2208I Volume G01309 deleted from storage
pool
                          SPTBUCOLDRMCP.
03/25/04   08:28:22      ANR9999D asvol.c(916): ThreadId<69>
NumEmptyVols went
                          negative for pool -11.
03/25/04   08:28:23      ANR1341I Scratch volume G01309 has been deleted
from
                          storage pool SPTBUCOLDRMCP.

Dale Jolliff
Data Administration Team
Backup and Recovery


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Wednesday, March 24, 2004 1:00 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: need help!! long time archiving and storing corresponding
systemstatus

Original requirement:
 the environment is w2k and nt client nodes (over 200) and in near
future
 w2003.
 short description of my problem:
 i have to archive data for long time retention, with the possibility to
 recover servers completely out of this archived data.

>thank you for your comment, using ntbackup was one of our suggestions
to
>solve this problem.
>in my opinion the solution with ntbackup will work, but the customer
don't
>want to have it.
>
>what about generating backupsets instead of archiving the data. is it
>possible to restore a complete server
>with a backupset?
>
> the problem will be the large amount of tapes for the backupsets.

I think your customer's requirements are confused and vaguely defined,
and that
is making the contemplation of solution confusing.

Your users are seemingly thinking of "the computer system" as their
data, and
are thus requiring that the whole think be preserved as an entity.
That's
faulty thinking, and thwarts the enterprise management of business data.
The business data should be physically and logically separate from the
platform which facilitates its use, which is to say that the data files
should
be in one area (disk, partition, or major directory) which is wholly
separate
from operating system and applications.  It is the data that is unique
and
needs to be regularly backed up to be recoverable: the operating system
and
applications are reinstallable things.

With that perspective, the TSM Archive system is the appropriate tool to
make long-term images of your organizational data - the kind of imaging
which
may be required by regulators or the like.  And you need to perform
regular
backups of the continually changing, daily business data.

Disaster recovery is facilitated by TSM DRM and/or other BMR methods,
which
allows recovery onto equivalent or comparable hardware.  Your recovery
plans
may instead involve no presumption upon being able to obtain any given
type
of computer, and so you may simply contemplate installing whatever OS
and
application levels you can obtain at the time of recovery, and restore
your
data thereafter, to be used by that current platform environment.

Don't let end users define IT and business practices: the IT department
and
company executives should do that.  IT should define how to best
implement
computer technology to facilitate business operation and possible
recovery:
IT has the expertise and experience to make it all work.

   Richard Sims

<Prev in Thread] Current Thread [Next in Thread>
  • 64 bit Oracle issue resolved; audit volume issues, Jolliff, Dale <=