Hi All,

We are in the process of planning the upgrade of our ASE
12.5.4 dataservers to ASE 15.x.  What is the most
recommended way to upgrade ASE dataservers from ASE 12.5.4
to ASE 15.x?

Potential options:

1)  Install new instances of ASE 15.x and load database
dumps from our ASE 12.5.4 dataservers to the newly installed
ASE 15.x dataservers.

- OR -

2)  Use the ASE upgrade utility (sqlupgrade) to upgrade our
existing ASE 12.5.4 dataservers to ASE 15.x.

What are the Pros vs. Cons for loading a 12.5.4 database
into a 15.x ASE dataserver versus performing an ASE
dataserver upgrade (from 12.5.x to 15.x)?

Thank you! :)

Susan L.

I have always prefered the option to have a dump-load. But my co-workers like the upgrade utility.If you can preserve the 12.5.4 
images for a few days after the 15.0x conversion then you will have an environment where you can do pre/post conversion testing 
if a proc does not perform as expected.

-- 
Cory Sane
[TeamSybase]
Certified Sybase Associate DBA for ASE 15.0
"Susan L." wrote in message news:4b811a22.3e1d.1681692777@sybase.com...
> Hi All,
>
> We are in the process of planning the upgrade of our ASE
> 12.5.4 dataservers to ASE 15.x.  What is the most
> recommended way to upgrade ASE dataservers from ASE 12.5.4
> to ASE 15.x?
>
> Potential options:
>
> 1)  Install new instances of ASE 15.x and load database
> dumps from our ASE 12.5.4 dataservers to the newly installed
> ASE 15.x dataservers.
>
> - OR -
>
> 2)  Use the ASE upgrade utility (sqlupgrade) to upgrade our
> existing ASE 12.5.4 dataservers to ASE 15.x.
>
> What are the Pros vs. Cons for loading a 12.5.4 database
> into a 15.x ASE dataserver versus performing an ASE
> dataserver upgrade (from 12.5.x to 15.x)?
>
> Thank you! :)
>
> Susan L. 

Thank you Cory for your response and feedback.

I like the dump/load approach as well, because it also gives
us an environment we can easily roll-back too if needed. 
Especially since our systems are front office / trading
systems, it will be important to have a contingency plan
(roll-back plan).

So when you load the 12.5.4 dumps into the 15.0.3
environment, will all the necessary upgrades to the database
take place automatically (i.e. systems tables, new features,
etc.)?

Because the dump/load approach seems to be so much simpler
and straight forward, I'd like to ask the following
questions...

Is there any drawback to using a dump/load approach?

Is there any advantage of using the upgrade utility
(sqlupgrade) instead of the dump/load approach?

What are your thoughts?

Thank you,

Susan L.



> I have always prefered the option to have a dump-load. But
> my co-workers like the upgrade utility.If you can preserve
> the 12.5.4  images for a few days after the 15.0x
> conversion then you will have an environment where you can
> do pre/post conversion testing  if a proc does not perform
> as expected.
>
> --
> Cory Sane
> [TeamSybase]
> Certified Sybase Associate DBA for ASE 15.0
> "Susan L." wrote in message
> > news:4b811a22.3e1d.1681692777@sybase.com... Hi All,
> >
> > We are in the process of planning the upgrade of our ASE
> > 12.5.4 dataservers to ASE 15.x.  What is the most
> > recommended way to upgrade ASE dataservers from ASE
> > 12.5.4 to ASE 15.x?
> >
> > Potential options:
> >
> > 1)  Install new instances of ASE 15.x and load database
> > dumps from our ASE 12.5.4 dataservers to the newly
> > installed ASE 15.x dataservers.
> >
> > - OR -
> >
> > 2)  Use the ASE upgrade utility (sqlupgrade) to upgrade
> > our existing ASE 12.5.4 dataservers to ASE 15.x.
> >
> > What are the Pros vs. Cons for loading a 12.5.4 database
> > into a 15.x ASE dataserver versus performing an ASE
> > dataserver upgrade (from 12.5.x to 15.x)?
> >
> > Thank you! :)
> >
> > Susan L.
>

> I like the dump/load approach as well, because it also gives
> us an environment we can easily roll-back too if needed. 
> Especially since our systems are front office / trading
> systems, it will be important to have a contingency plan
> (roll-back plan).

What's your definition of a contingency/rollback plan?

While you could switch back to the 12.5.4 dataserver, you'll be missing any data modifications (insert/update/delete, 
new logins/users, modified passwords, new DDL) that may have occurred on the 15.0.3 dataserver while it was up and running.

If you can live with the lost data ... fine.

If you can reproduce the lost data for inclusion in the 12.5.4 dataserver ... great.

If you need that data from ASE 15.0.3 but don't have it when you switch back to 12.5.4 ... *ouch* ... you've got a hole 
in your contingency/rollback plan.  ("Duh, Mark!" ?)

> So when you load the 12.5.4 dumps into the 15.0.3
> environment, will all the necessary upgrades to the database
> take place automatically (i.e. systems tables, new features,
> etc.)?

The newly loaded database will be run through the complete dataserver-level upgrade process as a result of running the 
'online database' command.

The DBA will still be responsible for post-upgrade steps such as ... the highly-recommended running of delete stats 
followed by update index stats ... changing monitoring scripts to take into account modified system functions ... 
dropping/recreating any T-SQL (eg, proc, triggers, etc) that require a rewrite to run properly (more efficiently?) under 
ASE 15.0.3 ... and on and on and on ... the size of this list depends on what you found during your thorough testing of 
ASE 15.0.3 in the dev/test environments.

> Because the dump/load approach seems to be so much simpler
> and straight forward, I'd like to ask the following
> questions...
> 
> Is there any drawback to using a dump/load approach?
> 
> Is there any advantage of using the upgrade utility
> (sqlupgrade) instead of the dump/load approach?

My answer to your questions ... "It depends."

Certainly having an ASE 12.5.4 instance you can revert back to (rollback?  post-upgrade testing/comparison? etc) has 
it's benefits.

I've performed 100+ production dataserver upgrades to ASE 15.x over the last few years, and of course quite a few 
dev/test/dr dataserver upgrades as well.  I don't recall ever using dump-n-load on the production systems (and rarely on 
the dev/test/dr systems).  This wasn't because dump-n-load had any drawbacks, but because we (my clients and I) had no 
reason not to use sqlupgrade.

Which method is best for your environment will probably come down to a question of which method your most comfortable 
with ... and which fits into your contigency/rollback plans best.

--------------

Off on a bit of a tangent ...

Upgrade contingency plans usually include one or more of the following:

- thorough testing in dev/test (when possible)

- sign-off from end users that they can reproduce ASE 15.x production data if we haveto downgrade to ASE 12.x

- full db dumps of all key databases prior to the upgrade; objective being to perform a dump-n-load (into a 12.x 
dataserver) if necessary as part of a downgrade step

- in replicated environments (WS, full MSA) keep the replicate at 12.x until the primary 15.x has bee burned in and 
accepted by the end users  [Since data is replicated from 15.x to 12.x, a rollback of the upgrade process - aka 
downgrade - consists of switching end users 'back' to the replicate dataserver.]

- sign-off from the end users that non-fatal issues (eg, poor performance) will be worked through (as opposed to 
downgrading); in other words, end users know there could be some 'pain' immediately after the upgrade as we work through 
performance issues [NOTE: I don't recommend anyone take this step unless they have folks on site who can work under a 
*bit* of pressure. ;-)  ]

Hi Mark,

Thank you for your great feedback.  Really appreciate your
detailed explanation.  Your feedback was really insightful.

As you pointed out, it is important to account for data
entered into the new 15.x environment (to prevent data
loss).  We were planning to use the Replication Server
solution you mention in your feedback.  We were going to
keep the Replica / Warm Standby at 12.5.4 until PROD proved
to be bug free.  Yet at the same time, the motivation of
keeping the old PROD 12.5.4 running / not overwritten, is to
have a primary site / onsite environment to perform a
dump/load from the Warm Standby 12.5.4 if a
rollback/contingency was needed.  We could use the Warm
Standby for a the rollback / downgrade, but management
prefers to have an onsite / primary site failover
environment instead.

So with that all said...  :)

So to our understanding the sqlupgrade utility overwrites
the old environment (the 12.5.4 instance / directory
structure).  Is that correct?

The reason I ask, because a part of the "upgrade"
process/steps, you have to install ASE 15.x into a separate
directory structure...

So after using the sqlupgrade utility, which directory
structure and instance will be left standing / in tact? 
Both?  The new 15.x instance / directory structure?  Or the
old 12.x instance / directory structure?

Thank you!

Susan L.



> > I like the dump/load approach as well, because it also
> > gives us an environment we can easily roll-back too if
> > needed.  Especially since our systems are front office /
> > trading systems, it will be important to have a
> > contingency plan (roll-back plan).
>
> What's your definition of a contingency/rollback plan?
>
> While you could switch back to the 12.5.4 dataserver,
> you'll be missing any data modifications
> (insert/update/delete,  new logins/users, modified
> passwords, new DDL) that may have occurred on the 15.0.3
> dataserver while it was up and running.
>
> If you can live with the lost data ... fine.
>
> If you can reproduce the lost data for inclusion in the
> 12.5.4 dataserver ... great.
>
> If you need that data from ASE 15.0.3 but don't have it
> when you switch back to 12.5.4 ... *ouch* ... you've got a
> hole  in your contingency/rollback plan.  ("Duh, Mark!" ?)
>
> > So when you load the 12.5.4 dumps into the 15.0.3
> > environment, will all the necessary upgrades to the
> > database take place automatically (i.e. systems tables,
> > new features, etc.)?
>
> The newly loaded database will be run through the complete
> dataserver-level upgrade process as a result of running
> the  'online database' command.
>
> The DBA will still be responsible for post-upgrade steps
> such as ... the highly-recommended running of delete stats
> followed by update index stats ... changing monitoring
> scripts to take into account modified system functions ...
> dropping/recreating any T-SQL (eg, proc, triggers, etc)
> that require a rewrite to run properly (more efficiently?)
> under  ASE 15.0.3 ... and on and on and on ... the size of
> this list depends on what you found during your thorough
> testing of  ASE 15.0.3 in the dev/test environments.
>
> > Because the dump/load approach seems to be so much
> > simpler and straight forward, I'd like to ask the
> > following questions...
> >
> > Is there any drawback to using a dump/load approach?
> >
> > Is there any advantage of using the upgrade utility
> > (sqlupgrade) instead of the dump/load approach?
>
> My answer to your questions ... "It depends."
>
> Certainly having an ASE 12.5.4 instance you can revert
> back to (rollback?  post-upgrade testing/comparison? etc)
> has  it's benefits.
>
> I've performed 100+ production dataserver upgrades to ASE
> 15.x over the last few years, and of course quite a few
> dev/test/dr dataserver upgrades as well.  I don't recall
> ever using dump-n-load on the production systems (and
> rarely on  the dev/test/dr systems).  This wasn't because
> dump-n-load had any drawbacks, but because we (my clients
> and I) had no  reason not to use sqlupgrade.
>
> Which method is best for your environment will probably
> come down to a question of which method your most
> comfortable  with ... and which fits into your
> contigency/rollback plans best.
>
> --------------
>
> Off on a bit of a tangent ...
>
> Upgrade contingency plans usually include one or more of
> the following:
>
> - thorough testing in dev/test (when possible)
>
> - sign-off from end users that they can reproduce ASE 15.x
> production data if we haveto downgrade to ASE 12.x
>
> - full db dumps of all key databases prior to the upgrade;
> objective being to perform a dump-n-load (into a 12.x
> dataserver) if necessary as part of a downgrade step
>
> - in replicated environments (WS, full MSA) keep the
> replicate at 12.x until the primary 15.x has bee burned in
> and  accepted by the end users  [Since data is replicated
> from 15.x to 12.x, a rollback of the upgrade process - aka
> downgrade - consists of switching end users 'back' to the
> replicate dataserver.]
>
> - sign-off from the end users that non-fatal issues (eg,
> poor performance) will be worked through (as opposed to
> downgrading); in other words, end users know there could
> be some 'pain' immediately after the upgrade as we work
> through  performance issues [NOTE: I don't recommend
> anyone take this step unless they have folks on site who
> can work under a  *bit* of pressure. ;-)  ]

Using repserver to keep a replicate 12.5.4 instance in sync sounds good.

Assuming you already have the replication up and running, then an upgrade-in-place for the PDS sounds like the easier 
method, as this means no changes for the replication environment.  On the other hand, if you were to upgrade the PDS via 
dump-n-load then you may have to rebuild parts of the replication system in order to support the newly created PDS (it 
may be possible to fake out the repserver into thinking the PDS hasn't changed, but that's a bit more complicated scenario).

As for directory structures, etc ...

Assuming you've installed the 15.0.x software in it's own directory structure ...

The sqlupgrade process will overwrite/modify the dataserver instance (ie, the changes will be made on the sybase devices).

The sqlupgrade process does nothing to the 12.5.4 installation directory.  Once the upgrade process has completed the 
12.5.4 directory will still be intact.

NOTE:  You'll still need to make sure the 15.0.3 directory structure is ready to use (eg, SYBASE.[c]sh, interfaces, 
*cfg, RUN* files are in place and configured properly for your environment).  Obviously (?) any monitoring and 
maintenance scripts, batch jobs, etc ... should be checked/modified to insure they're pointing at the 15.0.3 directory 
once the upgrade has been completed.

As for management's desire to have a local downgrade option (as opposed to switching to a remote location RDS), a few 
ideas come to mind ...

- move the RDS to a local machine; obviously the remote RDS could remain in place but it would not be of any use until 
it's re-synced

- reconfigure your replication environment to look like:

     PDS ---> (via WS) ---> local RDS ---> (via WS) ---> remote RDS

.... doable, but a bit complicated to setup/configure properly.

- replace your WS setup with a MSA setup; this would allow you to have two RDS instances, one local and one remote; the 
downside is that there's no 'switch active' command for MSA so you'll need to be careful about how you switch the PDS to 
the local RDS (in the case of a downgrade) while realizing that you'll need to reconfigure the 'new' PDS to replicate to 
the remote RDS (ie, you'll need to rebuild replication - drop/recreate db repdef/sub).

Susan L. wrote:
> Hi Mark,
> 
> Thank you for your great feedback.  Really appreciate your
> detailed explanation.  Your feedback was really insightful.
> 
> As you pointed out, it is important to account for data
> entered into the new 15.x environment (to prevent data
> loss).  We were planning to use the Replication Server
> solution you mention in your feedback.  We were going to
> keep the Replica / Warm Standby at 12.5.4 until PROD proved
> to be bug free.  Yet at the same time, the motivation of
> keeping the old PROD 12.5.4 running / not overwritten, is to
> have a primary site / onsite environment to perform a
> dump/load from the Warm Standby 12.5.4 if a
> rollback/contingency was needed.  We could use the Warm
> Standby for a the rollback / downgrade, but management
> prefers to have an onsite / primary site failover
> environment instead.
> 
> So with that all said...  :)
> 
> So to our understanding the sqlupgrade utility overwrites
> the old environment (the 12.5.4 instance / directory
> structure).  Is that correct?
> 
> The reason I ask, because a part of the "upgrade"
> process/steps, you have to install ASE 15.x into a separate
> directory structure...
> 
> So after using the sqlupgrade utility, which directory
> structure and instance will be left standing / in tact? 
> Both?  The new 15.x instance / directory structure?  Or the
> old 12.x instance / directory structure?
> 
> Thank you!
> 
> Susan L.
> 
> 
> 
>>> I like the dump/load approach as well, because it also
>>> gives us an environment we can easily roll-back too if
>>> needed.  Especially since our systems are front office /
>>> trading systems, it will be important to have a
>>> contingency plan (roll-back plan).
>> What's your definition of a contingency/rollback plan?
>>
>> While you could switch back to the 12.5.4 dataserver,
>> you'll be missing any data modifications
>> (insert/update/delete,  new logins/users, modified
>> passwords, new DDL) that may have occurred on the 15.0.3
>> dataserver while it was up and running.
>>
>> If you can live with the lost data ... fine.
>>
>> If you can reproduce the lost data for inclusion in the
>> 12.5.4 dataserver ... great.
>>
>> If you need that data from ASE 15.0.3 but don't have it
>> when you switch back to 12.5.4 ... *ouch* ... you've got a
>> hole  in your contingency/rollback plan.  ("Duh, Mark!" ?)
>>
>>> So when you load the 12.5.4 dumps into the 15.0.3
>>> environment, will all the necessary upgrades to the
>>> database take place automatically (i.e. systems tables,
>>> new features, etc.)?
>> The newly loaded database will be run through the complete
>> dataserver-level upgrade process as a result of running
>> the  'online database' command.
>>
>> The DBA will still be responsible for post-upgrade steps
>> such as ... the highly-recommended running of delete stats
>> followed by update index stats ... changing monitoring
>> scripts to take into account modified system functions ...
>> dropping/recreating any T-SQL (eg, proc, triggers, etc)
>> that require a rewrite to run properly (more efficiently?)
>> under  ASE 15.0.3 ... and on and on and on ... the size of
>> this list depends on what you found during your thorough
>> testing of  ASE 15.0.3 in the dev/test environments.
>>
>>> Because the dump/load approach seems to be so much
>>> simpler and straight forward, I'd like to ask the
>>> following questions...
>>>
>>> Is there any drawback to using a dump/load approach?
>>>
>>> Is there any advantage of using the upgrade utility
>>> (sqlupgrade) instead of the dump/load approach?
>> My answer to your questions ... "It depends."
>>
>> Certainly having an ASE 12.5.4 instance you can revert
>> back to (rollback?  post-upgrade testing/comparison? etc)
>> has  it's benefits.
>>
>> I've performed 100+ production dataserver upgrades to ASE
>> 15.x over the last few years, and of course quite a few
>> dev/test/dr dataserver upgrades as well.  I don't recall
>> ever using dump-n-load on the production systems (and
>> rarely on  the dev/test/dr systems).  This wasn't because
>> dump-n-load had any drawbacks, but because we (my clients
>> and I) had no  reason not to use sqlupgrade.
>>
>> Which method is best for your environment will probably
>> come down to a question of which method your most
>> comfortable  with ... and which fits into your
>> contigency/rollback plans best.
>>
>> --------------
>>
>> Off on a bit of a tangent ...
>>
>> Upgrade contingency plans usually include one or more of
>> the following:
>>
>> - thorough testing in dev/test (when possible)
>>
>> - sign-off from end users that they can reproduce ASE 15.x
>> production data if we haveto downgrade to ASE 12.x
>>
>> - full db dumps of all key databases prior to the upgrade;
>> objective being to perform a dump-n-load (into a 12.x
>> dataserver) if necessary as part of a downgrade step
>>
>> - in replicated environments (WS, full MSA) keep the
>> replicate at 12.x until the primary 15.x has bee burned in
>> and  accepted by the end users  [Since data is replicated
>> from 15.x to 12.x, a rollback of the upgrade process - aka
>> downgrade - consists of switching end users 'back' to the
>> replicate dataserver.]
>>
>> - sign-off from the end users that non-fatal issues (eg,
>> poor performance) will be worked through (as opposed to
>> downgrading); in other words, end users know there could
>> be some 'pain' immediately after the upgrade as we work
>> through  performance issues [NOTE: I don't recommend
>> anyone take this step unless they have folks on site who
>> can work under a  *bit* of pressure. ;-)  ]

Clarification ...

re:  replication already in place and performing an upgrade in place ...

You *will* need to make some changes to the replication system, namely:

- sp_stop_rep_agent <PDB>

- dbcc settrunc (ltm,ignore) [disable PDS trunc point]

- shutdown repserver (could probably leave up, but will definitely need to shutdown if RSSD is inside the PDS)

- upgrade PDS

- rs_zeroltm [reset trunc point in RSSD]

- dbcc settrunc (ltm,valid) [reset trunc point in PDB]

- sp_start_rep_agent <PDB>

Leaving the replication truncation point in place during the PDS upgrade can (in cases I've seen) lead to problems with 
the PDB log filling up and/or on occasion failure of the upgrade process, ymmv.


Mark A. Parsons wrote:
> Using repserver to keep a replicate 12.5.4 instance in sync sounds good.
> 
> Assuming you already have the replication up and running, then an 
> upgrade-in-place for the PDS sounds like the easier method, as this 
> means no changes for the replication environment.  On the other hand, if 
> you were to upgrade the PDS via dump-n-load then you may have to rebuild 
> parts of the replication system in order to support the newly created 
> PDS (it may be possible to fake out the repserver into thinking the PDS 
> hasn't changed, but that's a bit more complicated scenario).
> 
> As for directory structures, etc ...
> 
> Assuming you've installed the 15.0.x software in it's own directory 
> structure ...
> 
> The sqlupgrade process will overwrite/modify the dataserver instance 
> (ie, the changes will be made on the sybase devices).
> 
> The sqlupgrade process does nothing to the 12.5.4 installation 
> directory.  Once the upgrade process has completed the 12.5.4 directory 
> will still be intact.
> 
> NOTE:  You'll still need to make sure the 15.0.3 directory structure is 
> ready to use (eg, SYBASE.[c]sh, interfaces, *cfg, RUN* files are in 
> place and configured properly for your environment).  Obviously (?) any 
> monitoring and maintenance scripts, batch jobs, etc ... should be 
> checked/modified to insure they're pointing at the 15.0.3 directory once 
> the upgrade has been completed.
> 
> As for management's desire to have a local downgrade option (as opposed 
> to switching to a remote location RDS), a few ideas come to mind ...
> 
> - move the RDS to a local machine; obviously the remote RDS could remain 
> in place but it would not be of any use until it's re-synced
> 
> - reconfigure your replication environment to look like:
> 
>     PDS ---> (via WS) ---> local RDS ---> (via WS) ---> remote RDS
> 
> ... doable, but a bit complicated to setup/configure properly.
> 
> - replace your WS setup with a MSA setup; this would allow you to have 
> two RDS instances, one local and one remote; the downside is that 
> there's no 'switch active' command for MSA so you'll need to be careful 
> about how you switch the PDS to the local RDS (in the case of a 
> downgrade) while realizing that you'll need to reconfigure the 'new' PDS 
> to replicate to the remote RDS (ie, you'll need to rebuild replication - 
> drop/recreate db repdef/sub).
> 
> Susan L. wrote:
>> Hi Mark,
>>
>> Thank you for your great feedback.  Really appreciate your
>> detailed explanation.  Your feedback was really insightful.
>>
>> As you pointed out, it is important to account for data
>> entered into the new 15.x environment (to prevent data
>> loss).  We were planning to use the Replication Server
>> solution you mention in your feedback.  We were going to
>> keep the Replica / Warm Standby at 12.5.4 until PROD proved
>> to be bug free.  Yet at the same time, the motivation of
>> keeping the old PROD 12.5.4 running / not overwritten, is to
>> have a primary site / onsite environment to perform a
>> dump/load from the Warm Standby 12.5.4 if a
>> rollback/contingency was needed.  We could use the Warm
>> Standby for a the rollback / downgrade, but management
>> prefers to have an onsite / primary site failover
>> environment instead.
>>
>> So with that all said...  :)
>>
>> So to our understanding the sqlupgrade utility overwrites
>> the old environment (the 12.5.4 instance / directory
>> structure).  Is that correct?
>>
>> The reason I ask, because a part of the "upgrade"
>> process/steps, you have to install ASE 15.x into a separate
>> directory structure...
>>
>> So after using the sqlupgrade utility, which directory
>> structure and instance will be left standing / in tact? Both?  The new 
>> 15.x instance / directory structure?  Or the
>> old 12.x instance / directory structure?
>>
>> Thank you!
>>
>> Susan L.
>>
>>
>>
>>>> I like the dump/load approach as well, because it also
>>>> gives us an environment we can easily roll-back too if
>>>> needed.  Especially since our systems are front office /
>>>> trading systems, it will be important to have a
>>>> contingency plan (roll-back plan).
>>> What's your definition of a contingency/rollback plan?
>>>
>>> While you could switch back to the 12.5.4 dataserver,
>>> you'll be missing any data modifications
>>> (insert/update/delete,  new logins/users, modified
>>> passwords, new DDL) that may have occurred on the 15.0.3
>>> dataserver while it was up and running.
>>>
>>> If you can live with the lost data ... fine.
>>>
>>> If you can reproduce the lost data for inclusion in the
>>> 12.5.4 dataserver ... great.
>>>
>>> If you need that data from ASE 15.0.3 but don't have it
>>> when you switch back to 12.5.4 ... *ouch* ... you've got a
>>> hole  in your contingency/rollback plan.  ("Duh, Mark!" ?)
>>>
>>>> So when you load the 12.5.4 dumps into the 15.0.3
>>>> environment, will all the necessary upgrades to the
>>>> database take place automatically (i.e. systems tables,
>>>> new features, etc.)?
>>> The newly loaded database will be run through the complete
>>> dataserver-level upgrade process as a result of running
>>> the  'online database' command.
>>>
>>> The DBA will still be responsible for post-upgrade steps
>>> such as ... the highly-recommended running of delete stats
>>> followed by update index stats ... changing monitoring
>>> scripts to take into account modified system functions ...
>>> dropping/recreating any T-SQL (eg, proc, triggers, etc)
>>> that require a rewrite to run properly (more efficiently?)
>>> under  ASE 15.0.3 ... and on and on and on ... the size of
>>> this list depends on what you found during your thorough
>>> testing of  ASE 15.0.3 in the dev/test environments.
>>>
>>>> Because the dump/load approach seems to be so much
>>>> simpler and straight forward, I'd like to ask the
>>>> following questions...
>>>>
>>>> Is there any drawback to using a dump/load approach?
>>>>
>>>> Is there any advantage of using the upgrade utility
>>>> (sqlupgrade) instead of the dump/load approach?
>>> My answer to your questions ... "It depends."
>>>
>>> Certainly having an ASE 12.5.4 instance you can revert
>>> back to (rollback?  post-upgrade testing/comparison? etc)
>>> has  it's benefits.
>>>
>>> I've performed 100+ production dataserver upgrades to ASE
>>> 15.x over the last few years, and of course quite a few
>>> dev/test/dr dataserver upgrades as well.  I don't recall
>>> ever using dump-n-load on the production systems (and
>>> rarely on  the dev/test/dr systems).  This wasn't because
>>> dump-n-load had any drawbacks, but because we (my clients
>>> and I) had no  reason not to use sqlupgrade.
>>>
>>> Which method is best for your environment will probably
>>> come down to a question of which method your most
>>> comfortable  with ... and which fits into your
>>> contigency/rollback plans best.
>>>
>>> --------------
>>>
>>> Off on a bit of a tangent ...
>>>
>>> Upgrade contingency plans usually include one or more of
>>> the following:
>>>
>>> - thorough testing in dev/test (when possible)
>>>
>>> - sign-off from end users that they can reproduce ASE 15.x
>>> production data if we haveto downgrade to ASE 12.x
>>>
>>> - full db dumps of all key databases prior to the upgrade;
>>> objective being to perform a dump-n-load (into a 12.x
>>> dataserver) if necessary as part of a downgrade step
>>>
>>> - in replicated environments (WS, full MSA) keep the
>>> replicate at 12.x until the primary 15.x has bee burned in
>>> and  accepted by the end users  [Since data is replicated
>>> from 15.x to 12.x, a rollback of the upgrade process - aka
>>> downgrade - consists of switching end users 'back' to the
>>> replicate dataserver.]
>>>
>>> - sign-off from the end users that non-fatal issues (eg,
>>> poor performance) will be worked through (as opposed to
>>> downgrading); in other words, end users know there could
>>> be some 'pain' immediately after the upgrade as we work
>>> through  performance issues [NOTE: I don't recommend
>>> anyone take this step unless they have folks on site who
>>> can work under a  *bit* of pressure. ;-)  ]

Mark,

Thank you so much!!!  I can't express in words how much help
your feedback is.  Sincerely sincerely appreciate your time
and efforts.

Thank you,

Susan L.



> Clarification ...
>
> re:  replication already in place and performing an
> upgrade in place ...
>
> You *will* need to make some changes to the replication
> system, namely:
>
> - sp_stop_rep_agent <PDB>
>
> - dbcc settrunc (ltm,ignore) [disable PDS trunc point]
>
> - shutdown repserver (could probably leave up, but will
> definitely need to shutdown if RSSD is inside the PDS)
>
> - upgrade PDS
>
> - rs_zeroltm [reset trunc point in RSSD]
>
> - dbcc settrunc (ltm,valid) [reset trunc point in PDB]
>
> - sp_start_rep_agent <PDB>
>
> Leaving the replication truncation point in place during
> the PDS upgrade can (in cases I've seen) lead to problems
> with  the PDB log filling up and/or on occasion failure of
> the upgrade process, ymmv.
>
>
> Mark A. Parsons wrote:
> > Using repserver to keep a replicate 12.5.4 instance in
> > sync sounds good.
> > Assuming you already have the replication up and running
> > , then an  upgrade-in-place for the PDS sounds like the
> > easier method, as this  means no changes for the
> > replication environment.  On the other hand, if  you
> were to upgrade the PDS via dump-n-load then you may have
> > to rebuild  parts of the replication system in order to
> > support the newly created  PDS (it may be possible to
> > fake out the repserver into thinking the PDS  hasn't
> > changed, but that's a bit more complicated scenario).
> > As for directory structures, etc ...
> >
> > Assuming you've installed the 15.0.x software in it's
> > own directory  structure ...
> >
> > The sqlupgrade process will overwrite/modify the
> > dataserver instance  (ie, the changes will be made on
> > the sybase devices).
> > The sqlupgrade process does nothing to the 12.5.4
> > installation  directory.  Once the upgrade process has
> > completed the 12.5.4 directory  will still be intact.
> >
> > NOTE:  You'll still need to make sure the 15.0.3
> > directory structure is  ready to use (eg, SYBASE.[c]sh,
> > interfaces, *cfg, RUN* files are in  place and
> configured properly for your environment).  Obviously (?)
> > any  monitoring and maintenance scripts, batch jobs, etc
> > ... should be  checked/modified to insure they're
> > pointing at the 15.0.3 directory once  the upgrade has
> > been completed.
> > As for management's desire to have a local downgrade
> > option (as opposed  to switching to a remote location
> > RDS), a few ideas come to mind ...
> > - move the RDS to a local machine; obviously the remote
> > RDS could remain  in place but it would not be of any
> > use until it's re-synced
> > - reconfigure your replication environment to look like:
> >
> >     PDS ---> (via WS) ---> local RDS ---> (via WS) --->
> > remote RDS
> > ... doable, but a bit complicated to setup/configure
> > properly.
> > - replace your WS setup with a MSA setup; this would
> > allow you to have  two RDS instances, one local and one
> > remote; the downside is that  there's no 'switch active'
> > command for MSA so you'll need to be careful  about how
> > you switch the PDS to the local RDS (in the case of a
> downgrade) while realizing that you'll need to reconfigure
> > the 'new' PDS  to replicate to the remote RDS (ie,
> > you'll need to rebuild replication -  drop/recreate db
> > repdef/sub).
> > Susan L. wrote:
> >> Hi Mark,
> >>
> >> Thank you for your great feedback.  Really appreciate
> your >> detailed explanation.  Your feedback was really
> insightful. >>
> >> As you pointed out, it is important to account for data
> >> entered into the new 15.x environment (to prevent data
> >> loss).  We were planning to use the Replication Server
> >> solution you mention in your feedback.  We were going
> to >> keep the Replica / Warm Standby at 12.5.4 until PROD
> proved >> to be bug free.  Yet at the same time, the
> motivation of >> keeping the old PROD 12.5.4 running / not
> overwritten, is to >> have a primary site / onsite
> environment to perform a >> dump/load from the Warm
> Standby 12.5.4 if a >> rollback/contingency was needed.
> We could use the Warm >> Standby for a the rollback /
> downgrade, but management >> prefers to have an onsite /
> primary site failover >> environment instead.
> >>
> >> So with that all said...  :)
> >>
> >> So to our understanding the sqlupgrade utility
> overwrites >> the old environment (the 12.5.4 instance /
> directory >> structure).  Is that correct?
> >>
> >> The reason I ask, because a part of the "upgrade"
> >> process/steps, you have to install ASE 15.x into a
> separate >> directory structure...
> >>
> >> So after using the sqlupgrade utility, which directory
> >> structure and instance will be left standing / in tact?
> Both?  The new  >> 15.x instance / directory structure?
> Or the >> old 12.x instance / directory structure?
> >>
> >> Thank you!
> >>
> >> Susan L.
> >>
> >>
> >>
> >>>> I like the dump/load approach as well, because it
> also >>>> gives us an environment we can easily roll-back
> too if >>>> needed.  Especially since our systems are
> front office / >>>> trading systems, it will be important
> to have a >>>> contingency plan (roll-back plan).
> >>> What's your definition of a contingency/rollback plan?
> >>>
> >>> While you could switch back to the 12.5.4 dataserver,
> >>> you'll be missing any data modifications
> >>> (insert/update/delete,  new logins/users, modified
> >>> passwords, new DDL) that may have occurred on the
> 15.0.3 >>> dataserver while it was up and running.
> >>>
> >>> If you can live with the lost data ... fine.
> >>>
> >>> If you can reproduce the lost data for inclusion in
> the >>> 12.5.4 dataserver ... great.
> >>>
> >>> If you need that data from ASE 15.0.3 but don't have
> it >>> when you switch back to 12.5.4 ... *ouch* ...
> you've got a >>> hole  in your contingency/rollback plan.
> ("Duh, Mark!" ?) >>>
> >>>> So when you load the 12.5.4 dumps into the 15.0.3
> >>>> environment, will all the necessary upgrades to the
> >>>> database take place automatically (i.e. systems
> tables, >>>> new features, etc.)?
> >>> The newly loaded database will be run through the
> complete >>> dataserver-level upgrade process as a result
> of running >>> the  'online database' command.
> >>>
> >>> The DBA will still be responsible for post-upgrade
> steps >>> such as ... the highly-recommended running of
> delete stats >>> followed by update index stats ...
> changing monitoring >>> scripts to take into account
> modified system functions ... >>> dropping/recreating any
> T-SQL (eg, proc, triggers, etc) >>> that require a rewrite
> to run properly (more efficiently?) >>> under  ASE 15.0.3
> .. and on and on and on ... the size of >>> this list
> depends on what you found during your thorough >>> testing
> of  ASE 15.0.3 in the dev/test environments. >>>
> >>>> Because the dump/load approach seems to be so much
> >>>> simpler and straight forward, I'd like to ask the
> >>>> following questions...
> >>>>
> >>>> Is there any drawback to using a dump/load approach?
> >>>>
> >>>> Is there any advantage of using the upgrade utility
> >>>> (sqlupgrade) instead of the dump/load approach?
> >>> My answer to your questions ... "It depends."
> >>>
> >>> Certainly having an ASE 12.5.4 instance you can revert
> >>> back to (rollback?  post-upgrade testing/comparison?
> etc) >>> has  it's benefits.
> >>>
> >>> I've performed 100+ production dataserver upgrades to
> ASE >>> 15.x over the last few years, and of course quite
> a few >>> dev/test/dr dataserver upgrades as well.  I
> don't recall >>> ever using dump-n-load on the production
> systems (and >>> rarely on  the dev/test/dr systems).
> This wasn't because >>> dump-n-load had any drawbacks, but
> because we (my clients >>> and I) had no  reason not to
> use sqlupgrade. >>>
> >>> Which method is best for your environment will
> probably >>> come down to a question of which method your
> most >>> comfortable  with ... and which fits into your
> >>> contigency/rollback plans best.
> >>>
> >>> --------------
> >>>
> >>> Off on a bit of a tangent ...
> >>>
> >>> Upgrade contingency plans usually include one or more
> of >>> the following:
> >>>
> >>> - thorough testing in dev/test (when possible)
> >>>
> >>> - sign-off from end users that they can reproduce ASE
> 15.x >>> production data if we haveto downgrade to ASE
> 12.x >>>
> >>> - full db dumps of all key databases prior to the
> upgrade; >>> objective being to perform a dump-n-load
> (into a 12.x >>> dataserver) if necessary as part of a
> downgrade step >>>
> >>> - in replicated environments (WS, full MSA) keep the
> >>> replicate at 12.x until the primary 15.x has bee
> burned in >>> and  accepted by the end users  [Since data
> is replicated >>> from 15.x to 12.x, a rollback of the
> upgrade process - aka >>> downgrade - consists of
> switching end users 'back' to the >>> replicate
> dataserver.] >>>
> >>> - sign-off from the end users that non-fatal issues
> (eg, >>> poor performance) will be worked through (as
> opposed to >>> downgrading); in other words, end users
> know there could >>> be some 'pain' immediately after the
> upgrade as we work >>> through  performance issues [NOTE:
> I don't recommend >>> anyone take this step unless they
> have folks on site who >>> can work under a  *bit* of
> pressure. ;-)  ]