While I'm not sure, I think the problem is deeper than just the database.
It might also be
byte ordering and other issues with you data on tape. In other words, even
if IBM
came up with a way to export/import the db to a different type of server
(which they
could . . . .Oracle did it), it might still require a conversion of the
data on all your tapes.
Paul Zarnowski
<psz1 AT CORNELL DOT EDU
> To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
Dist Stor cc
Manager"
<[email protected] Subject
.EDU> Re: migrate 32bit database -> 64bit
TSM server?
09/18/2006 12:18
PM
Please respond to
"ADSM: Dist Stor
Manager"
<[email protected]
.EDU>
Thanks Victoria.
Ok, so now I know it won't work (in addition to not being supported).
Next questions:
1. How hard would it be for IBM to do something to help users do this?
2. How many TSM sites would actually want to do this?
I.e., is there reason to submit a requirement for this, or are we just
trying to do something that not many folks ever want to do?
At 11:32 AM 9/18/2006, Victoria Ortepio wrote:
>Hi Paul,
>
>
>
>No, it cannot be done. We've proved it here by taking a TSM data snapshot
>
>and attempting to restore it a newly built TSM server on LINUX. This is
>
>the result. Unfortunately, the EXPORT / IMPORT option is your only
>
>alternative. You may selectively choose what to export out to cut down
>
>the conversion time.
>
>
>
>
>
>Tivoli Storage Manager for Linux/i386
>
>Version 5, Release 2, Level 7.0
>
>Licensed Materials - Property of IBM
>
>(C) Copyright IBM Corporation 1990, 2003. All rights reserved.
>
>U.S. Government Users Restricted Rights - Use, duplication or disclosure
>
>restricted by GSA ADP Schedule Contract with IBM Corporation.
>
>
>
>ANR7800I DSMSERV generated at 01:59:13 on Dec 8 2005.
>
>ANR7801I Subsystem process ID is 6806.
>
>ANR0900I Processing options file /usr/tivoli/tsm/server/bin/dsmserv.opt.
>
>ANR8200I TCP/IP driver ready for connection with clients on port 1500.
>
>ANR0200I Recovery log assigned capacity is 5696 megabytes.
>
>ANR0201I Database assigned capacity is 15888 megabytes.
>
>ANR4621I Database backup device class TSM-DATABASE.
>
>ANR4622I Volume 1: /TSM03S/40709557.dbs.
>
>ANR4632I Starting point-in-time database restore (no commit).
>
>ANR8340I FILE volume /TSM03S/40709557.dbs mounted.
>
>ANR1368W Input volume /TSM03S/40709557.dbs contains sequence number
>16777216;
>
>volume sequence number 1 is required.
>
>[root@asr0100570 bin]#
>
>
>
>Please refer to this website for info:
>
>
>
>http://www-1.ibm.com/support/docview.wss?uid=swg21189573
>
>
>
>
>
>Regards,
>
>
>
>Vicki
>
>Verizon Business
>
>Piscataway, NJ
>
>
>
>
>
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
>Paul Zarnowski
>Sent: Monday, September 18, 2006 10:39 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: [ADSM-L] migrate 32bit database -> 64bit TSM server?
>
>
>
>We are considering moving our server from AIX to another unix OS
>
>(probably Linux). I was hoping that we could just restore a backup
>
>of our DB to a Linux server and have it point to the same tapes. But
>
>the initial feedback I've gotten indicates that this is not
>
>supported. No one has told me that it won't work, just that it's not
>
>supported. Given how long it would take to export/import all of our
>
>(archive) data, this leaves us with some difficult choices. It sure
>
>would be nice if TSM had a supported way of doing this more
>
>efficiently than export/import.
>
>
>
>The other problem with export/import is that all of our clients would
>
>then have to change their config files to point to the new
>
>server. If we could simply restore the DB onto the new server, that
>
>new server could inherit the same hostname and port numbers as the
>
>old server, making the whole server migration transparent to our
>
>hundreds of end users.
>
>
>
>At 03:46 AM 9/17/2006, Mark Stapleton wrote:
>
> >You will not be able to move your TSM db from Windows to Linux (or from
>
> >any OS to any other dissimilar OS). The file structures are too
different.
>
> >
>
> >Your best bet to have both servers up. Use the new one for backups and
use
>
> >the old one (as necessary) for restored of legacy information. If you're
>
> >using the original library for the new server, there are elements of
>
> >problems with this.
>
> >
>
> >After a period of time determined by your business needs, just turn off
>
> >the old server.
>
> >
>
> >Do not consider export/import choices for client data. Exports and
imports
>
> >TAKE TOO #%^#^&%@$!! LONG! (Listening, Tivoli?)
>
>
>
>
>
>--
>
>Paul Zarnowski Ph: 607-255-4757
>
>Manager, Storage Services Fx: 607-255-8521
>
>719 Rhodes Hall, Ithaca, NY 14853-3801 Em: psz1 AT cornell DOT edu
--
Paul Zarnowski Ph: 607-255-4757
Manager, Storage Services Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801 Em: psz1 AT cornell DOT edu
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
|
