Jan,

IMO, TDPs do not use NQR, since an application alsways knows the names of
the objects to be restored, so wildcard
is not sent to the server, hence no NQR...it is not an API limitation, it
is just not needed. I am sure that TSM API provides a developer
a way to send a wildcarded object specification to the TSM server, the
point is that it is up to an application whether to utilize this
functionality.

I would expect to see API to use LAN path in case SAN path fails for any
reason (for example an object is stored in the disk storage pool so it is
not
accesible through SA)...so are you saying it does not do this?


Sergey






"Norback, Jan" <Jan.Norback AT ATOSORIGIN DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
05/12/2003 12:18 AM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        LAN and SAN backups. Don't expect that you can restore 
your backu ps   if
you have a mixed LAN/SAN environment.



Do you believe that your end user can restore without the TSM admins
involvement?
Forget that if you are running in a mixed LAN and LAN free backup
environment. I appreciate you comments on the below:

We are supporting a number of larger SAP databases using TDP for SAP and
TDP
for SQL (or is it IBM Tivoli Data Protection for Databases now?...). The
online backups are going LAN free but the transaction logs (redologs) are
going over the LAN to a disk pool. This works perfect and it makes it
possible for us to have a good utilization of our tape drives with
controlled migration of the logs instead of tape drive competition. TSM
truly backs up anything anywhere and completely transparent to the end
users.

Restoring is a completely different area, it no longer works! In fact the
only alert that things are not working is in the end of a restore of an
SQL
Server when it fails with a read error. It fails because the transaction
logs hadn't migrated yet from the disk storage pool to tape. There is no
documentation in the manuals for TDP for XYZ that warns about this major
limitation, the only semi documentation related to this is in the Storage
Agent manual where it states:
-"Dual-session No-Query Restore  for LAN-free Path: When performing a
No-Query restore the TSM server builds a list of files to restore and
sends
data to the client while continuing to build  the list. This type of
restore
is more efficient especially in a LAN-free  environment, and allows the
restore to be restarted if interrupted. Two sessions  are used for the
restore when data for the restore resides on devices with a  LAN-free path
and devices with a LAN-only path. One session restores data from  the
server
with a LAN-only path. The other session uses the storage agent to  restore
data over the LAN-free path."
Here the manual talks about  "more efficient especially in a LAN-free
environment". That is very correct as there is absolutely no way of
getting
the data unless reconfiguration (or getting TSM sys admin involved for a
migration). It doesn't say that a query restore will fail! The manual also
explains that:
-"The  server determines if the client is  requesting access to storage
for
which the client has a SAN path defined. If a SAN path is defined, the
client (by means of the storage agent)  transfers data on that path."
To me that sounds that data residing on the disk should be transferred
over
the LAN. However, this is a no go when data requested is partly on a disk
pool and partly in the tape pool.

I can't find any limitation in the API documentation, nor can I find it in
the TDP for R/3 or SQL server documentation. The UNIX client BA and
Install
guide do not mention this major limitation for the "enablelanfree yes".
Nowhere is it clear that the products built on top of the API can't use
the
"No-Query " restore and that they will fail in a mixed LAN/SAN environment
as this!

I have opened a PMR in which I have asked IBM to fix this that I see as a
major problem, the order of my expectation for this fix where:
-Make sure that TSM can handle mixed LAN/SAN restores and once again
becomes
the tool we are used to have.
-Get the developer of the TDP for XYZ to utilize the API such that
"No-Query
restores" are used. (Don't know if this is possible).
-At least clearly document this limitations in all manuals with
information
on how to handle the problem. It has to be clear for the TSM admin that
migration must be very frequent for this setup. It would also be good if
the
TDP tooling had a "test-restore" facility that could warn for this and
alert
with a suggested work around.

None of the above was accepted by IBM. They don't see this as a bug and I
have been asked to submit a Design Enhancement Request or a Design Change
Request for this.

Regards,
Jan Norback
Tivoli Certified Consultant: ADSM/TSM
IBM Cert. Adv. Technical Expert RS/6000 AIX
Atos Origin-IT (MS/DS/OSS Unix)
VA-106
Groenewoudseweg 1
5621 BA Eindhoven, The Netherlands
Email: Jan.Norback AT Atosorigin DOT com
Tel: +31 (0)40-2780289
Mobile: +31 (0)6-12994492
Fax     : +31 40 2783962