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.
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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. >
![]() |
0 |
![]() |
> 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. ;-) ]
![]() |
0 |
![]() |
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. ;-) ]
![]() |
0 |
![]() |
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. ;-) ]
![]() |
0 |
![]() |
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. ;-) ]
![]() |
0 |
![]() |
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. ;-) ]
![]() |
0 |
![]() |