TDP monitoring

2003-02-13 Thread Wholey, Joseph (TGA\\MLOL)
Tyring to get a general survey of how TSMers managing large scale deployments of TDP 
for Oracle.

Since it's a client driven process (in our environment), the success or failure is 
difficult to monitor.
Also, TDPOSYNC requires information only the DBAs would know.
e.g.Catalog user name
Catalog Password
Catalog Connect String


How do most people manage that?  How do you keep a DBA honest and make sure he runs it?
Any info would be greatly appreciated.

Regards, Joe



Re: TDP monitoring

2003-02-13 Thread Wholey, Joseph (TGA\\MLOL)
Bill,

How would you pass this info on the command line  as it prompts you for it when 
you execute TDPOSYNC.

Catalog user name
Catalog Password
Catalog Connect String

-Original Message-
From: Bill Boyer [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 13, 2003 9:52 AM
To: [EMAIL PROTECTED]
Subject: Re: TDP monitoring


Let your DBA create the shell scripts and RMAN scripts for the backups and
TDPOSYNC, then YOU schedule them via TSM. Create a command schedule that
SU's to the Oracle user and runs the shell script(s). The result is then
posted as the completion code for the schedule event. The DBA (or whoever
creates the shell scripts) needs to make sure and return from the script
with an meaningfull code.

Like su - ORACLE -c /path/to/shell/script.sh

Bill Boyer
My problem was caused by a loose screw at the keyboard - ??

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Wholey, Joseph (TGA\MLOL)
Sent: Thursday, February 13, 2003 9:45 AM
To: [EMAIL PROTECTED]
Subject: TDP monitoring


Tyring to get a general survey of how TSMers managing large scale
deployments of TDP for Oracle.

Since it's a client driven process (in our environment), the success or
failure is difficult to monitor.
Also, TDPOSYNC requires information only the DBAs would know.
e.g.Catalog user name
Catalog Password
Catalog Connect String


How do most people manage that?  How do you keep a DBA honest and make sure
he runs it?
Any info would be greatly appreciated.

Regards, Joe



Re: TDP monitoring

2002-03-01 Thread Rushforth, Tim

10 or 20 Exchange IS restores in progress at the same time not being
unusual???

I would worry about why you have to do that!

The e-mail support group shold be able to do the restores themselves with
the TDP GUI - and it shows the progess.

-Original Message-
From: Wholey, Joseph (TGA\MLOL) [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 28, 2002 6:26 PM
To: [EMAIL PROTECTED]
Subject: Re: TDP monitoring


Tim, Del,

Thanks... how about monitoring a restore in progress?  Or monitoring many in
progress (like 10 or 20 which would not be that unusual). For example, your
e-mail support group paging and asking when is
it going to finish?
Is it simply Q the size of the full and the incrs and do the math?  That's
kind of cumbersome for multiple restores.

Regards, Joe



Re: TDP monitoring

2002-03-01 Thread Wholey, Joseph (TGA\\MLOL)

Server upgrade.

-Original Message-
From: Rushforth, Tim [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 01, 2002 10:07 AM
To: [EMAIL PROTECTED]
Subject: Re: TDP monitoring


10 or 20 Exchange IS restores in progress at the same time not being
unusual???

I would worry about why you have to do that!

The e-mail support group shold be able to do the restores themselves with
the TDP GUI - and it shows the progess.

-Original Message-
From: Wholey, Joseph (TGA\MLOL) [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 28, 2002 6:26 PM
To: [EMAIL PROTECTED]
Subject: Re: TDP monitoring


Tim, Del,

Thanks... how about monitoring a restore in progress?  Or monitoring many in
progress (like 10 or 20 which would not be that unusual). For example, your
e-mail support group paging and asking when is
it going to finish?
Is it simply Q the size of the full and the incrs and do the math?  That's
kind of cumbersome for multiple restores.

Regards, Joe



Re: TDP monitoring

2002-03-01 Thread Wholey, Joseph (TGA\\MLOL)

When running the Exchange full backup via a schedule, a C:\WINNT4\system32\cmd.exe 
window pops up on the client that is getting the Exchange full backup.  Any way to 
stop that, or get it to run in
the background?

Thanks, Joe



-Original Message-
From: Rushforth, Tim [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 01, 2002 10:07 AM
To: [EMAIL PROTECTED]
Subject: Re: TDP monitoring


10 or 20 Exchange IS restores in progress at the same time not being
unusual???

I would worry about why you have to do that!

The e-mail support group shold be able to do the restores themselves with
the TDP GUI - and it shows the progess.

-Original Message-
From: Wholey, Joseph (TGA\MLOL) [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 28, 2002 6:26 PM
To: [EMAIL PROTECTED]
Subject: Re: TDP monitoring


Tim, Del,

Thanks... how about monitoring a restore in progress?  Or monitoring many in
progress (like 10 or 20 which would not be that unusual). For example, your
e-mail support group paging and asking when is
it going to finish?
Is it simply Q the size of the full and the incrs and do the math?  That's
kind of cumbersome for multiple restores.

Regards, Joe



TDP monitoring

2002-02-28 Thread Wholey, Joseph (TGA\\MLOL)

I'm currently testing TDP for Exchange for possible deployment in a very large 
enterprise environment.  Is anyone aware of tools/scripts that I can use to monitor 
the backups/restores.  I'm aware that
I can look at the past history of backups/restores and determine approximately how 
long it will take, however, this can be quite time consuming.  Also, does anyone know 
how most people are monitoring
the success/failure of their respective backups.  I was going to scrape data out of 
the excfull.log or excincr.log.  This seems kind of primitive.

Regards,
Joe Wholey
TGA Distributed Data Services
Merrill Lynch
Phone: 212-647-3018
Page:  888-637-7450
E-mail: [EMAIL PROTECTED]



Re: TDP monitoring

2002-02-28 Thread Del Hoobler

 I'm currently testing TDP for Exchange for possible deployment
 in a very large enterprise environment.  Is anyone aware of
 tools/scripts that I can use to monitor the backups/restores.
 I'm aware that
 I can look at the past history of backups/restores and
 determine approximately how long it will take, however,
 this can be quite time consuming.  Also, does anyone
 know how most people are monitoring
 the success/failure of their respective backups.  I
 was going to scrape data out of the excfull.log or
 excincr.log.  This seems kind of primitive.

Joe,

Just one thought...
Also, keep in mind that all backup (and restore) events
for TDP for Exchange are logged in the TSM server
activity log... including their success or failure.
That way you can go to one central location
to find out the status of the backups, i.e. you
would not have to go to each Exchange server
to find out the status.

Thanks,

Del



Del Hoobler
IBM Corporation
[EMAIL PROTECTED]

Celebrate we will. Life is short but sweet for certain...  -- Dave



Re: TDP monitoring

2002-02-28 Thread Rushforth, Tim

Not all error messages for TDP For Exchange (1.1.1.01 anyways) are logged on
the server.

We just ran into this on one of our test servers, messages in client log:
ACN3002E --
The Directory service is not running. A backup was attempted
but the necessary Exchange Services were not running.
01/29/2002 20:59:31,ACN3025E -- Backup error encountered.

On the server, all you see is
01/28/2002 21:00:02  ANR2561I Schedule prompter contacting EX-CSDSVTEMB

  (session 2400) to start a scheduled operation.

01/28/2002 21:00:03  ANR0406I Session 2403 started for node EX-CSDSVTEMB

  (WinNT) (Tcp/Ip 192.168.176.45(4083)).

01/28/2002 21:00:16  ANR0403I Session 2403 ended for node EX-CSDSVTEMB
(WinNT).

Now this may be a bad example because if it is a production system you would
know pretty quick that the directory service was not running on Exchange!

We monitor all backups via q event to look for failed schedules (this does
not catch all Exchange Failures)

We do a daily check for filespaces that have not been backed up (this will
catch Exchange failures).

We also run a report using the accounting file as input which will show you
how much data is backed up by each node and the throughput.

Tim Rushforth
City of Winnipeg

-Original Message-
From: Del Hoobler [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 28, 2002 3:42 PM
To: [EMAIL PROTECTED]
Subject: Re: TDP monitoring


 I'm currently testing TDP for Exchange for possible deployment
 in a very large enterprise environment.  Is anyone aware of
 tools/scripts that I can use to monitor the backups/restores.
 I'm aware that
 I can look at the past history of backups/restores and
 determine approximately how long it will take, however,
 this can be quite time consuming.  Also, does anyone
 know how most people are monitoring
 the success/failure of their respective backups.  I
 was going to scrape data out of the excfull.log or
 excincr.log.  This seems kind of primitive.

Joe,

Just one thought...
Also, keep in mind that all backup (and restore) events
for TDP for Exchange are logged in the TSM server
activity log... including their success or failure.
That way you can go to one central location
to find out the status of the backups, i.e. you
would not have to go to each Exchange server
to find out the status.

Thanks,

Del



Del Hoobler
IBM Corporation
[EMAIL PROTECTED]

Celebrate we will. Life is short but sweet for certain...  -- Dave



Re: TDP monitoring

2002-02-28 Thread Wholey, Joseph (TGA\\MLOL)

Tim, Del,

Thanks... how about monitoring a restore in progress?  Or monitoring many in progress 
(like 10 or 20 which would not be that unusual). For example, your e-mail support 
group paging and asking when is
it going to finish?
Is it simply Q the size of the full and the incrs and do the math?  That's kind of 
cumbersome for multiple restores.

Regards, Joe

-Original Message-
From: Rushforth, Tim [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 28, 2002 5:42 PM
To: [EMAIL PROTECTED]
Subject: Re: TDP monitoring

Not all error messages for TDP For Exchange (1.1.1.01 anyways) are logged on
the server.

We just ran into this on one of our test servers, messages in client log:
ACN3002E --
The Directory service is not running. A backup was attempted
but the necessary Exchange Services were not running.
01/29/2002 20:59:31,ACN3025E -- Backup error encountered.

On the server, all you see is
01/28/2002 21:00:02  ANR2561I Schedule prompter contacting EX-CSDSVTEMB

  (session 2400) to start a scheduled operation.

01/28/2002 21:00:03  ANR0406I Session 2403 started for node EX-CSDSVTEMB

  (WinNT) (Tcp/Ip 192.168.176.45(4083)).

01/28/2002 21:00:16  ANR0403I Session 2403 ended for node EX-CSDSVTEMB
(WinNT).

Now this may be a bad example because if it is a production system you would
know pretty quick that the directory service was not running on Exchange!

We monitor all backups via q event to look for failed schedules (this does
not catch all Exchange Failures)

We do a daily check for filespaces that have not been backed up (this will
catch Exchange failures).

We also run a report using the accounting file as input which will show you
how much data is backed up by each node and the throughput.

Tim Rushforth
City of Winnipeg

-Original Message-
From: Del Hoobler [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 28, 2002 3:42 PM
To: [EMAIL PROTECTED]
Subject: Re: TDP monitoring


 I'm currently testing TDP for Exchange for possible deployment
 in a very large enterprise environment.  Is anyone aware of
 tools/scripts that I can use to monitor the backups/restores.
 I'm aware that
 I can look at the past history of backups/restores and
 determine approximately how long it will take, however,
 this can be quite time consuming.  Also, does anyone
 know how most people are monitoring
 the success/failure of their respective backups.  I
 was going to scrape data out of the excfull.log or
 excincr.log.  This seems kind of primitive.

Joe,

Just one thought...
Also, keep in mind that all backup (and restore) events
for TDP for Exchange are logged in the TSM server
activity log... including their success or failure.
That way you can go to one central location
to find out the status of the backups, i.e. you
would not have to go to each Exchange server
to find out the status.

Thanks,

Del



Del Hoobler
IBM Corporation
[EMAIL PROTECTED]

Celebrate we will. Life is short but sweet for certain...  -- Dave



Re: TDP monitoring

2002-02-28 Thread Christo Heuer

What we used to do is just look at the file spaces - which
used to pretty accurate (Days since last backup completed
successfully 1) and pull out any machine that is greater
than 1 - now with the TDP for exchange 2.2 client it reports
the filespace as successfully completed even if a storage
group in exchange failed it's backup.
Have not bothered opening a call for this because as Del says,
all the actual messages are logged to the server - we pull it
out of there including other info like the throughput for
the session. This way of reporting seems the most accurate.

Cheers
Christo



 I'm currently testing TDP for Exchange for possible deployment
 in a very large enterprise environment.  Is anyone aware of
 tools/scripts that I can use to monitor the backups/restores.
 I'm aware that
 I can look at the past history of backups/restores and
 determine approximately how long it will take, however,
 this can be quite time consuming.  Also, does anyone
 know how most people are monitoring
 the success/failure of their respective backups.  I
 was going to scrape data out of the excfull.log or
 excincr.log.  This seems kind of primitive.

Joe,

Just one thought...
Also, keep in mind that all backup (and restore) events
for TDP for Exchange are logged in the TSM server
activity log... including their success or failure.
That way you can go to one central location
to find out the status of the backups, i.e. you
would not have to go to each Exchange server
to find out the status.

Thanks,

Del



Del Hoobler
IBM Corporation
[EMAIL PROTECTED]

Celebrate we will. Life is short but sweet for certain...  -- Dave
__
The information contained in this communication is confidential and
may be legally privileged.  It is intended solely for the use of the
individual or entity to whom it is addressed and others authorised to
receive it.  If you are not the intended recipient you are hereby
notified that any disclosure, copying, distribution or taking action
in reliance of the contents of this information is strictly prohibited
and may be unlawful.  Absa is neither liable for the proper, complete
transmission of the information contained in this communication, any
delay in its receipt or that the mail is virus-free.