Converting NT 11.5 ASE to a Solaris 12.5 ASE

We are trying to migrate a server running on Windows NT to a Solaris
machine.  The NT box is running ASE 11.5 and the Solaris box is running
12.5.  So far, the only way we have came up with to migrate the data is bcp.
The problem is we estimate this to be probably about a 6-7 hour process.
Our shop runs 24*7*365 and unfortunately downtime is not something we get.
In the past when we have migrated servers, we have used warm-standby which
has worked really nicely.  But in this case we can't run dump and load to
populate the database.
Has anyone been able to migrate an NT box to a Unix box with a method other
than bcp?  If so, I would be really interested in hearing how you did it and
how much downtime you had to take as a result.
Thx,
Grant Carter
---------------------------------------------------
Grant A. Carter
Boise, ID

0
Grant
3/27/2002 1:37:51 AM
📁 sybase.ase.unix
📃 866 articles.
⭐ 0 followers.

💬 11 Replies
👁️‍🗨️ 811 Views


"Grant A. Carter" wrote:
> 
> We are trying to migrate a server running on Windows NT to a Solaris
> machine.  The NT box is running ASE 11.5 and the Solaris box is running
> 12.5.  So far, the only way we have came up with to migrate the data is bcp.
        There are actually 3 - bcp, the BCP API or CIS.
> The problem is we estimate this to be probably about a 6-7 hour process.
> Our shop runs 24*7*365 and unfortunately downtime is not something we get.
        Not even over quiet periods like Easter?
        Some obvious questions would be - how large is your data set?
        Have you tried copying tables over in parallel? This may depend
        on your network bandwidth and the disk i/o subsystem on the
        Solaris side (for the writes - reads shouldn't be as critical).
        What tuning have you explored so far to get maximum performance
        for the migration? What timeframe are you considering for the
        migration? If its soon, how prepared are you?
> In the past when we have migrated servers, we have used warm-standby which
> has worked really nicely.  But in this case we can't run dump and load to
> populate the database.
        That's correct. Intel and Sparc processors have different endianess.
> Has anyone been able to migrate an NT box to a Unix box with a method other
> than bcp?  If so, I would be really interested in hearing how you did it and
> how much downtime you had to take as a result.
        Since you can't use the warm standby method due to the hardware
        architecture, some down time will be required. The CIS approach
        (using proxy tables) might be the most effective. You can migrate
        partially and use proxy tables to point back to the ASE 11.5 server
        on NT for unmigrated tables then do them at a later date(s). Using
        CIS over a lot of proxied tables may have some performance
        implications that you should consider.
-am     � 2002
0
Anthony
3/27/2002 3:48:42 AM
Thank you for your suggestions.  We will be migrating databases that have
several tables with 2+ million rows.  In fact one of the tables is up toward
100 million rows.
We support a 24*7 manufacturing operation that works 365 days a year.
Manufacturing runs even on Christmas...  One thing we looked at is setting
up straight replication and then at some point take 15 minutes of downtime
to play switcharoo with the servers.  We would have probably 600 or so
tables to replicate, so the setup takes a lot of time but we could pull it
off with minimal downtime.
Thanks again for the input.
Grant Carter
Boise, Idaho

"Anthony Mandic" <sp_am_block@start.com.au> wrote in message
news:3CA1411A.D2666B29@start.com.au...
> "Grant A. Carter" wrote:
> >
> > We are trying to migrate a server running on Windows NT to a Solaris
> > machine.  The NT box is running ASE 11.5 and the Solaris box is running
> > 12.5.  So far, the only way we have came up with to migrate the data is
bcp.
>
> There are actually 3 - bcp, the BCP API or CIS.
>
> > The problem is we estimate this to be probably about a 6-7 hour process.
> > Our shop runs 24*7*365 and unfortunately downtime is not something we
get.
>
> Not even over quiet periods like Easter?
>
> Some obvious questions would be - how large is your data set?
> Have you tried copying tables over in parallel? This may depend
> on your network bandwidth and the disk i/o subsystem on the
> Solaris side (for the writes - reads shouldn't be as critical).
> What tuning have you explored so far to get maximum performance
> for the migration? What timeframe are you considering for the
> migration? If its soon, how prepared are you?
>
> > In the past when we have migrated servers, we have used warm-standby
which
> > has worked really nicely.  But in this case we can't run dump and load
to
> > populate the database.
>
> That's correct. Intel and Sparc processors have different endianess.
>
> > Has anyone been able to migrate an NT box to a Unix box with a method
other
> > than bcp?  If so, I would be really interested in hearing how you did it
and
> > how much downtime you had to take as a result.
>
> Since you can't use the warm standby method due to the hardware
> architecture, some down time will be required. The CIS approach
> (using proxy tables) might be the most effective. You can migrate
> partially and use proxy tables to point back to the ASE 11.5 server
> on NT for unmigrated tables then do them at a later date(s). Using
> CIS over a lot of proxied tables may have some performance
> implications that you should consider.
>
> -am � 2002

0
Grant
3/27/2002 4:38:23 AM
sftwear@yahoo.com wrote...
> Thank you for your suggestions.  We will be migrating databases that have
> several tables with 2+ million rows.  In fact one of the tables is up toward
> 100 million rows.
> 
> We support a 24*7 manufacturing operation that works 365 days a year.
> Manufacturing runs even on Christmas...  One thing we looked at is setting
> up straight replication and then at some point take 15 minutes of downtime
> to play switcharoo with the servers.  We would have probably 600 or so
> tables to replicate, so the setup takes a lot of time but we could pull it
> off with minimal downtime.
> 
Replication is indeed the preferred method for this type of migration.  I think the 
replication setup might be a lot easier than you think.  If it's more than you want to deal 
with then you might want to consider contacting Sybase Professional Services.  If you are 
who I think you are then your company has already worked with SPS on a number of projects.
-- 
Jim Egan [TeamSybase]
Senior Consultant
Sybase Professional Services
0
Jim
3/27/2002 5:44:23 AM
"Grant A. Carter" wrote:
> 
> Thank you for your suggestions.  We will be migrating databases that have
> several tables with 2+ million rows.  In fact one of the tables is up toward
> 100 million rows.
        Of that data, do the rows have a surrogate, monotonically increasing
        primary key and are old rows ever deleted or updated?
> We support a 24*7 manufacturing operation that works 365 days a year.
        Sounds a lot like Micron.
> Manufacturing runs even on Christmas...  One thing we looked at is setting
> up straight replication and then at some point take 15 minutes of downtime
> to play switcharoo with the servers.  We would have probably 600 or so
> tables to replicate, so the setup takes a lot of time but we could pull it
> off with minimal downtime.
        Yes, that's possible too.
-am     � 2002
0
Anthony
3/27/2002 6:41:44 AM
Here's a method that only requires people get out of the old database long
enough to dump it. Tell me what you think about this.
Phase One:
1) Install repserver and configure with generous amounts of stable device.
2) create the repdefs
3) define, activate, and validate the subscriptions but don't materialize
them yet.
4) suspend the connection to the replicate database
DO NOT  MARK PRIMARY OBJECTS FOR REPLICATION YET!
Phase Two: (do this quick)
1) kick everyone off primary database
2) dump the primary
3) mark the primary objects for replication
4) let everyone back in to the primary
At this point, all changes to the primary will pile up in the outbound queue
for the replicate database, and your dump image contains what the database
should look like prior to any further changes taking place.  If you can get
this dump image into the replicate and then resume the connection to the
replicate, your databases will be in sync and repserver will keep them that
way.
Phase Three:
1) load the dump to another database
2) bcp out of the newly loaded database
3) bcp in to the replicate database
4) resume the connection to the replicate database
Important notes:
1) If you use identity columns in the primary database, make sure that you
use identity as the datatype in the repdef.
2) If you use timestamp columns in the primary, leave them out of the repdef
altogether.
3) If you want to make the transfer process go faster, try this in the
Solaris box:
   mkfifo fifo
   bcp targetdb..targettable in fifo ....... > bcpin.log &
   bcp sourcedb..sourcetable out fifo > bcpout.log
The named pipe (i called it fifo) is a first-in-first-out buffer.  As the
bcpout writes data to the buffer, the bcpin (running in the background) will
read it.  When the bcpout completes and closes the file (fifo), the bcpin
will detect this as an end of file and complete.  This allows the bcpin to
operate in parallel (albeit with a bit of latency) with the bcpout, and the
buffer will only be as big as the difference between the bcpout and the
bcpin.  This can cut the transfer time nearly in half.
Good Luck and let us know how you come out.
Jason Webster
"Grant A. Carter" <sftwear@yahoo.com> wrote in message
news:6z7LUET1BHA.214@forums.sybase.com...
> We are trying to migrate a server running on Windows NT to a Solaris
> machine.  The NT box is running ASE 11.5 and the Solaris box is running
> 12.5.  So far, the only way we have came up with to migrate the data is
bcp.
> The problem is we estimate this to be probably about a 6-7 hour process.
> Our shop runs 24*7*365 and unfortunately downtime is not something we get.
>
> In the past when we have migrated servers, we have used warm-standby which
> has worked really nicely.  But in this case we can't run dump and load to
> populate the database.
>
> Has anyone been able to migrate an NT box to a Unix box with a method
other
> than bcp?  If so, I would be really interested in hearing how you did it
and
> how much downtime you had to take as a result.
>
> Thx,
> Grant Carter
> ---------------------------------------------------
> Grant A. Carter
> Boise, ID
>
>

0
Jason
3/27/2002 9:34:43 PM
That is almost like warm standby.  Problem is byte order (big endian vs.
little endian) going from NT to Solaris will not allow a Solaris box to load
an NT dump.
We have used warm standby in the past to migrate server with 0 downtime, but
in this case the dump and load isn't a valid option because of the byte
order.
Maybe I missed something here and if I did, please let me know.
Thx,
Grant Carter
"Jason Webster" <jason.webster`@mail.state.ky.us> wrote in message
news:RrDgygd1BHA.204@forums.sybase.com...
> Here's a method that only requires people get out of the old database long
> enough to dump it. Tell me what you think about this.
>
> Phase One:
> 1) Install repserver and configure with generous amounts of stable device.
> 2) create the repdefs
> 3) define, activate, and validate the subscriptions but don't materialize
> them yet.
> 4) suspend the connection to the replicate database
> DO NOT  MARK PRIMARY OBJECTS FOR REPLICATION YET!
>
> Phase Two: (do this quick)
> 1) kick everyone off primary database
> 2) dump the primary
> 3) mark the primary objects for replication
> 4) let everyone back in to the primary
>
> At this point, all changes to the primary will pile up in the outbound
queue
> for the replicate database, and your dump image contains what the database
> should look like prior to any further changes taking place.  If you can
get
> this dump image into the replicate and then resume the connection to the
> replicate, your databases will be in sync and repserver will keep them
that
> way.
>
> Phase Three:
> 1) load the dump to another database
> 2) bcp out of the newly loaded database
> 3) bcp in to the replicate database
> 4) resume the connection to the replicate database
>
> Important notes:
> 1) If you use identity columns in the primary database, make sure that you
> use identity as the datatype in the repdef.
> 2) If you use timestamp columns in the primary, leave them out of the
repdef
> altogether.
> 3) If you want to make the transfer process go faster, try this in the
> Solaris box:
>    mkfifo fifo
>    bcp targetdb..targettable in fifo ....... > bcpin.log &
>    bcp sourcedb..sourcetable out fifo > bcpout.log
>
> The named pipe (i called it fifo) is a first-in-first-out buffer.  As the
> bcpout writes data to the buffer, the bcpin (running in the background)
will
> read it.  When the bcpout completes and closes the file (fifo), the bcpin
> will detect this as an end of file and complete.  This allows the bcpin to
> operate in parallel (albeit with a bit of latency) with the bcpout, and
the
> buffer will only be as big as the difference between the bcpout and the
> bcpin.  This can cut the transfer time nearly in half.
>
> Good Luck and let us know how you come out.
>
> Jason Webster
>
> "Grant A. Carter" <sftwear@yahoo.com> wrote in message
> news:6z7LUET1BHA.214@forums.sybase.com...
> > We are trying to migrate a server running on Windows NT to a Solaris
> > machine.  The NT box is running ASE 11.5 and the Solaris box is running
> > 12.5.  So far, the only way we have came up with to migrate the data is
> bcp.
> > The problem is we estimate this to be probably about a 6-7 hour process.
> > Our shop runs 24*7*365 and unfortunately downtime is not something we
get.
> >
> > In the past when we have migrated servers, we have used warm-standby
which
> > has worked really nicely.  But in this case we can't run dump and load
to
> > populate the database.
> >
> > Has anyone been able to migrate an NT box to a Unix box with a method
> other
> > than bcp?  If so, I would be really interested in hearing how you did it
> and
> > how much downtime you had to take as a result.
> >
> > Thx,
> > Grant Carter
> > ---------------------------------------------------
> > Grant A. Carter
> > Boise, ID
> >
> >
>
>

0
Grant
3/28/2002 4:14:14 AM
sftwear@yahoo.com wrote...
> That is almost like warm standby.  Problem is byte order (big endian vs.
> little endian) going from NT to Solaris will not allow a Solaris box to load
> an NT dump.
> 
> We have used warm standby in the past to migrate server with 0 downtime, but
> in this case the dump and load isn't a valid option because of the byte
> order.
> 
There is supposed to be a feature in Rep Server that will allow you to replicate from an 
active database to an empty database.  It will move all the data over to the empty database 
while also getting the new data there also.
-- 
Jim Egan [TeamSybase]
Senior Consultant
Sybase Professional Services
0
Jim
3/28/2002 4:50:40 AM
Jim Egan wrote:
> There is supposed to be a feature in Rep Server that will allow you to replicate
> from an active database to an empty database.  It will move all the data over to
> the empty database while also getting the new data there also.
        Bulk materialisation. Anyone know if the logs have to wait before
        they get replicated over? If so, you'd need a very large log to
        cope with the expected size while waiting on a very large database
        to be replicated. It could get ugly.
-am     � 2002
0
Anthony
3/28/2002 7:10:21 AM
The log in the primary only has to wait if the rep agent can't forward ltl
to the repserver.  If the repserver has enough stable storage and the rep
agent stays up, the primary log won't fill due to the secondary truncation
point not moving.

"Anthony Mandic" <sp_am_block@start.com.au> wrote in message
news:3CA2C1DD.B0EA0578@start.com.au...
> Jim Egan wrote:
>
> > There is supposed to be a feature in Rep Server that will allow you to
replicate
> > from an active database to an empty database.  It will move all the data
over to
> > the empty database while also getting the new data there also.
>
> Bulk materialisation. Anyone know if the logs have to wait before
> they get replicated over? If so, you'd need a very large log to
> cope with the expected size while waiting on a very large database
> to be replicated. It could get ugly.
>
> -am � 2002

0
Jason
3/28/2002 6:39:31 PM
There are a couple of ways to do it, but one of them holds a lock on the
table in the primary, and I don't remember what the other is.

"Jim Egan" <dontspam.dbaguru@eganomics.com> wrote in message
news:MPG.170c4f104b1ee61398bc97@forums.sybase.com...
> sftwear@yahoo.com wrote...
> > That is almost like warm standby.  Problem is byte order (big endian vs.
> > little endian) going from NT to Solaris will not allow a Solaris box to
load
> > an NT dump.
> >
> > We have used warm standby in the past to migrate server with 0 downtime,
but
> > in this case the dump and load isn't a valid option because of the byte
> > order.
> >
>
> There is supposed to be a feature in Rep Server that will allow you to
replicate from an
> active database to an empty database.  It will move all the data over to
the empty database
> while also getting the new data there also.
> --
> Jim Egan [TeamSybase]
> Senior Consultant
> Sybase Professional Services

0
Jason
3/28/2002 6:40:52 PM
Perhaps I wasn't clear. You wouldn't load the nt dump on solaris,  that
absolutely won't work.  Instead, load it back to an nt installation and move
the data with bcp.
bcp works fine between different platforms, but if you run into problems you
can always resort to creating a separate database on the target server and
use cis to move the data.
"Grant A. Carter" <sftwear@yahoo.com> wrote in message
news:UkCrYAh1BHA.285@forums.sybase.com...
> That is almost like warm standby.  Problem is byte order (big endian vs.
> little endian) going from NT to Solaris will not allow a Solaris box to
load
> an NT dump.
>
> We have used warm standby in the past to migrate server with 0 downtime,
but
> in this case the dump and load isn't a valid option because of the byte
> order.
>
> Maybe I missed something here and if I did, please let me know.
>
> Thx,
> Grant Carter
>
> "Jason Webster" <jason.webster`@mail.state.ky.us> wrote in message
> news:RrDgygd1BHA.204@forums.sybase.com...
> > Here's a method that only requires people get out of the old database
long
> > enough to dump it. Tell me what you think about this.
> >
> > Phase One:
> > 1) Install repserver and configure with generous amounts of stable
device.
> > 2) create the repdefs
> > 3) define, activate, and validate the subscriptions but don't
materialize
> > them yet.
> > 4) suspend the connection to the replicate database
> > DO NOT  MARK PRIMARY OBJECTS FOR REPLICATION YET!
> >
> > Phase Two: (do this quick)
> > 1) kick everyone off primary database
> > 2) dump the primary
> > 3) mark the primary objects for replication
> > 4) let everyone back in to the primary
> >
> > At this point, all changes to the primary will pile up in the outbound
> queue
> > for the replicate database, and your dump image contains what the
database
> > should look like prior to any further changes taking place.  If you can
> get
> > this dump image into the replicate and then resume the connection to the
> > replicate, your databases will be in sync and repserver will keep them
> that
> > way.
> >
> > Phase Three:
> > 1) load the dump to another database
> > 2) bcp out of the newly loaded database
> > 3) bcp in to the replicate database
> > 4) resume the connection to the replicate database
> >
> > Important notes:
> > 1) If you use identity columns in the primary database, make sure that
you
> > use identity as the datatype in the repdef.
> > 2) If you use timestamp columns in the primary, leave them out of the
> repdef
> > altogether.
> > 3) If you want to make the transfer process go faster, try this in the
> > Solaris box:
> >    mkfifo fifo
> >    bcp targetdb..targettable in fifo ....... > bcpin.log &
> >    bcp sourcedb..sourcetable out fifo > bcpout.log
> >
> > The named pipe (i called it fifo) is a first-in-first-out buffer.  As
the
> > bcpout writes data to the buffer, the bcpin (running in the background)
> will
> > read it.  When the bcpout completes and closes the file (fifo), the
bcpin
> > will detect this as an end of file and complete.  This allows the bcpin
to
> > operate in parallel (albeit with a bit of latency) with the bcpout, and
> the
> > buffer will only be as big as the difference between the bcpout and the
> > bcpin.  This can cut the transfer time nearly in half.
> >
> > Good Luck and let us know how you come out.
> >
> > Jason Webster
> >
> > "Grant A. Carter" <sftwear@yahoo.com> wrote in message
> > news:6z7LUET1BHA.214@forums.sybase.com...
> > > We are trying to migrate a server running on Windows NT to a Solaris
> > > machine.  The NT box is running ASE 11.5 and the Solaris box is
running
> > > 12.5.  So far, the only way we have came up with to migrate the data
is
> > bcp.
> > > The problem is we estimate this to be probably about a 6-7 hour
process.
> > > Our shop runs 24*7*365 and unfortunately downtime is not something we
> get.
> > >
> > > In the past when we have migrated servers, we have used warm-standby
> which
> > > has worked really nicely.  But in this case we can't run dump and load
> to
> > > populate the database.
> > >
> > > Has anyone been able to migrate an NT box to a Unix box with a method
> > other
> > > than bcp?  If so, I would be really interested in hearing how you did
it
> > and
> > > how much downtime you had to take as a result.
> > >
> > > Thx,
> > > Grant Carter
> > > ---------------------------------------------------
> > > Grant A. Carter
> > > Boise, ID
> > >
> > >
> >
> >
>
>

0
Jason
3/28/2002 6:46:11 PM
Reply: