The fishing opener has come and gone. I was able to get out for the morning on the day of the opener, from about 6 AM to 11:30 AM. I went with my brother-in-law down to Pewaukee Lake, where we tried to find some early season muskies. I ended up with two follow-ups, one that fled as soon as it saw the boat, and another beauty of a fish that was very aggressive. It followed the lure in hot, right on its tail. It was a bigger fish (somewhere between 40 and 45 inches by my estimation), so instead of doing a figure 8 I went with a big continuous circle next to the boat. I ended up circling somewhere around 10 times with the fish following closely. Each time I swung the lure out away from the boat, the fish would cut the turn and make like it was going to t-bone the lure, but stopped just short. Finally, as I swung the lure back toward the boat, the large fish simply nudged it without even opening its mouth. It clearly was wary, and didn’t want to commit without investigating a bit more. After the nudge the fish took off, I’m sure because it felt the different between a real fish and my plastic Shallow Raider. The follow was a great start to the fishing season, but I’m hoping for more catches this year, not just follows. I did get this largemouth bass as a consolation catch:
Last week I completed an upgrade of the Oracle database in our Production environment. We only have a single application running on our Oracle database as compared to numerous applications running against SQL Server, so I’m not nearly as familiar with working in Oracle. To put it bluntly, I was quite nervous to do the upgrade, and practiced several times in our Test environment before proceeding with the Production upgrade. I was nervous for good reason because the upgrade did not go smoothly at all.
In our Test environment, it took me 3 or 4 tries before I was able to successfully complete the upgrade. I found a few major hurdles to clear:
- I needed a new user created. We currently had a domain user running the existing Oracle database service, but the installer complained that the existing user had some flavor of domain admin rights, and it would not let me proceed with that user.
- Our startup parameter file had a parameter called os_authent_prefix, which was set to doman\. When the upgrade ran I kept getting error messages caused by the \. I guess the upgrade assistant was not smart enough to deal with it, so I removed that parameter before the upgrade, then added it back in afterward. This is an important note! If you are doing an upgrade in the Windows environment, you will probably run into this issue.
- I had to set the job_queue_processes parameter to a higher number, 100.
- I dropped a few deprecated startup parameters, remote_os_authent and cursor_space_for_time. I ended up adding the remote_os_authent back in after the upgrade had completed.
- Lastly, Before the upgrade I compile invalid objects with the UTLRP.SQL job and emptied the Oracle recycle bin.
In addition to those issues which were causing the upgrade process to completely bomb, once I fixed them and got the upgrade to complete I had some cleanup, including the PATH and TNS_ADMIN environment variables, which had to point to the new Oracle home folder structure, and the tnsnames.ora and listener.ora files in the new Oracle home needed to be updated. By the last practice attempt I was getting through the upgrade process in around an hour.
Finally, the night arrived for the Production upgrade. The application is only used during business hours, so I started it at 5 PM once the normal users were finished for the day. The first thing I noticed is a difference in Environment Variables between our Production and Test environment. Production has the ORACLE_HOME environment variable set, and Test does not. This somehow caused the first upgrade attempt to completely fail. Not only did it fail, but it somehow erased the OracleDB service from the list of services in Windows. It took me quite a while to get it back and working again so I could make a second attempt at the upgrade. Although I received some error messages, this one did end up completing successfully. The one thing I wasn’t expecting though was the amount of time it took. While the database that was the same size but on inferior hardware took less than an hour to install in the Test environment, in our Production environment it took well over three hours to install.
I had to perform similar cleanup on the Production environment as in Test, but I also ran into one additional hiccup. After the upgrade I found all accounts except for sys were expired and locked. Now, unlocking an account is not a big problem, but there is not good way to unexpire an account. This is a big problem because many of the accounts can be service accounts, where no actual user is signing in. So no prompt for a new password, and no way to unexpire. Fortunately I found a great workaround on a blog post by Simon Krenger. This method involves replacing the existing encrypted password with that same encrypted password. Once I executed the SQL output by his method, all the accounts were unexpired.
The last step was to gather stats on the relevant databases, and the upgrade was complete.