Upgrade 11.50 to 12.10
Answered: amber (solid confidence) — Several concrete upgrade gotchas were offered (ER/cdr check repair, CONVERSION_GUARD, free-space headroom, and the OPT_SEEK_FACTOR index-seek regression); Mark thanked responders and planned a baseline/compare test, but the upgrade outcome itself isn't confirmed in-thread.
Advisory only.
Posted in 2018
A DBA planning an in-place upgrade of two heavily Enterprise Replication-linked Solaris instances from 11.50.FC9W2 to 12.10.FC10 asked for gotchas. Advice given: removing ER isn't strictly required, but if you drop and redefine it, run 'cdr check repl/replicateset ... -repair' afterwards (available since 11.7) to resync; consider the CONVERSION_GUARD feature to roll back a failed migration instead of a full restore (the poster relies on NetApp snapshots instead); keep ~30% free space in each dbspace; and if complex multi-column indexes show post-upgrade query slowdowns that UPDATE STATISTICS HIGH doesn't fix, tune the OPT_SEEK_FACTOR onconfig parameter (settable online with onmode -wf). No outcome of the actual upgrade is reported.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: High Availability & Replication, Installation, Setup & Upgrades, Server Administration, Networking & sqlhosts Configuration, Platform-Specific Issues
We have two large database engines running on Solaris 11.1 with a large amount of Enterprise Replication between them. In the near future I will be doing an upgrade from 11.50.FC9W2 up to 12.10.FC10 I understand it is an in-place update, 64 bit to 64 bit. We use Net-App SSD disks with Instant snapshots as well as taking Veritas NetBackup copies via On-bar. I intend to take the usual precautions during upgrade: 1) Remove ER replication before upgrade 2) Perform consistency checks before upgrade, cc, ce and cr. too large for more indepth checks. 3) Take full snapshot backup before upgrade. 4) Move aside the existing Informix directories etc 5) Perform the upgrade into fresh copy of Informix directory. 6) Copy in revised versions of the 12.10 onconfig, sqlhosts and .snversions file 7) Perform consistency checks 8) Check connectivity from local and remote hosts. 9) Put ER back. This upgrade process will be tested in SIT and Pre-prod before performed in Live. I have been warned about turning off auto update statistics as I have scripts to update stats in parallel. Are there any "Gotchas" that I should know about? Has anyone experienced any issues doing this upgrade? Any advise would be helpful, except "Have I considered running update stats :)" Thanks guys Mark
It's not necessary to remove ER to do the upgrade, but if you do then it would be wise to run cdr check repair when you reestablish ER. Sent from Yahoo Mail on Android On Mon, Jan 15, 2018 at 4:42 AM, MARK ATKINSON<masoftware@hotmail.co.uk> wrote: We have two large database engines running on Solaris 11.1 with a large amount of Enterprise Replication between them. In the near future I will be doing an upgrade from 11.50.FC9W2 up to 12.10.FC10 I understand it is an in-place update, 64 bit to 64 bit. We use Net-App SSD disks with Instant snapshots as well as taking Veritas NetBackup copies via On-bar. I intend to take the usual precautions during upgrade: 1) Remove ER replication before upgrade 2) Perform consistency checks before upgrade, cc, ce and cr. too large for more indepth checks. 3) Take full snapshot backup before upgrade. 4) Move aside the existing Informix directories etc 5) Perform the upgrade into fresh copy of Informix directory. 6) Copy in revised versions of the 12.10 onconfig, sqlhosts and .snversions file 7) Perform consistency checks 8) Check connectivity from local and remote hosts. 9) Put ER back. This upgrade process will be tested in SIT and Pre-prod before performed in Live. I have been warned about turning off auto update statistics as I have scripts to update stats in parallel. Are there any "Gotchas" that I should know about? Has anyone experienced any issues doing this upgrade? Any advise would be helpful, except "Have I considered running update stats :)" Thanks guys Mark ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
Hi Madison, Thanks for your response. I was planning to "cdr delete replicate" for each replicate and then "cdr delete server" for each side to reduce risk during the upgrade and also to not have to run the concdr.sh script. I have scripts to manage the dropping and creation of the replicate servers, also for creating, starting and stopping the replicates in the servers. I assume leaving the "crcols" will have no effect on the upgrade? Does the "cdr check repair" command only work if CDR is defined, ie the servers have not been dropped? Looks like this command is not in 11.50. Happy to run this command once the servers have been rebuilt and replicates defined and started. Thanks Mark
cdr check is based on the ER definitions and has been part of cdr somce 11.7The actual command is cdr check repl <repl name> -repair or cdr check replicateset <set name> -repair. You would need to run this after defining ER. Sent from Yahoo Mail on Android On Mon, Jan 15, 2018 at 8:32 AM, MARK ATKINSON<masoftware@hotmail.co.uk> wrote: Hi Madison, Thanks for your response. I was planning to "cdr delete replicate" for each replicate and then "cdr delete server" for each side to reduce risk during the upgrade and also to not have to run the concdr.sh script. I have scripts to manage the dropping and creation of the replicate servers, also for creating, starting and stopping the replicates in the servers. I assume leaving the "crcols" will have no effect on the upgrade? Does the "cdr check repair" command only work if CDR is defined, ie the servers have not been dropped? Looks like this command is not in 11.50. Happy to run this command once the servers have been rebuilt and replicates defined and started. Thanks Mark ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
Thanks Madison, will do. Any other thoughts on the upgrade?
For the - unlikely - event of something going wrong during the upgrade, be sure you're familiar with and using CONVERSION_GUARD feature. This was designed to save you a full fledged whole system restore to get back to pre-migration state and would instead simply 'roll back' all pages modified during migration. From: "MARK ATKINSON" <masoftware@hotmail.co.uk> To: ids@iiug.org Date: 01/15/2018 10:53 PM Subject: Re: Upgrade 11.50 to 12.10 [40504] Sent by: ids-bounces@iiug.org Thanks Madison, will do. Any other thoughts on the upgrade? ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
Just don't forget to have around 30% of free space in each of your dbspaces, and you will be fine. Regards.
Many Thanks Andreas for your suggestion. I am quite lucky at this site as I am using NetApp snapshot functionality. This provides Instant Backup before the upgrade and Instant Recovery in the event of a failure during the upgrade process. regs Mark
Hi Alexandre, Many thanks for your response. Yes I have kept on top of the free space and we are not far off 30% free in all spaces. kind regards Mark
Mark,
just in case, because this happened at one of my customers:
in case you have complex(ie index having many columns) indexes, it may happen
that some queries will show a severe performance drop in performance.
IN that case, if you UPDATE STATISTICS HIGH for these_tables does not solve
anything, you want to set a new ONCONFIG parameter OPT_SEEK_FACTOR as
described in this article
http://www-01.ibm.com/support/docview.wss?uid=swg21645369
you can set it online with onmode -wf
Beyond that, you will find a substantial overall performance gain, and of
course tons of new functionality including JSON/NoSQL, smart triggers and many
more
Eric
Many thanks Eric. We are planning a full scale application performance test. We will have a "baseline" of a days worth of activity ran through 11.50. We will then restore and upgrade. Then do the same test and compare results. If there not favourable then this parameter may prove handy :). Regs Mark