As I was poking around metalink, I found the following extremely interesting section. It’s in a very obvious place, but it’s new, so many of you may have not noticed it. It’s called “Support case studies” and provides some amazing articles.
When I read Note: 391116.1 with the full list, I noticed the following bugs that we’ve encountered are fixed. Unfortunately, an important bug in 10.2.0.2 posted on the Sept. 29 is not listed as fixed in this patch list.
One day I came up with the following neat idea. Start a second listener, on a different port, calling it the emergency listener. Then renice the listener process with higher priority. Now, every time I connect to the database via my emergency listener, my connection gets higher priority, and thus feels like there’s no problem with the database’s resource use.
There is one little caveat however. You need to either have access to root, or have a nice SA that will add renice to your sudoers file .
I have submitted an abstract for my new presentation about linux/unix memory and Oracle to the Rocky Mountain Oracle Users Group for the Training Days in Denver on February 14-15, 2007. I pilot tested it at the Ottawa Oracle User Group in June. The feedback was good and since then I have kept developing the presentation. Soon to be submitted for HotSos 2007.
It looks like Oracle has started testing the 10.2.0.3 patchset. A preliminary list of bugs fixed is at in MetaLink note 391116.1. The “important” bug fixes are here.
In this second part , I will outline more details of a new STATSPACK methodology. As I mentioned in previous part , the statspack_setting table is a bridge between the user and Oracle’s STATSPACK.
I was looking for known issues under 10.2.0.2 (which are notoriously hard to find by searching MetaLink) and came across this note that mentioned 220.127.116.11. Looking up patch number 4547809 on Oracle’s FTP site (use your MetaLink credentials to log in), I see that it was released for Windows 32/64-bit, HP/UX 64-bit, and MVS (!) overnight:
A client asked me, “How can I move a table to another schema in Oracle?” The quick answer I gave him is, “not possible”. You have to rebuild it via “create table as select”. You might ask, justifiably, why would you want to do that anyway? His problem was that the application has been split into 2 parts, and he wanted to have separate schemas for each part, to ensure that there is no cross-schema table access.
There’s always these little things that you discover when you read the manuals. For example the “duration” option for RMAN backup. It looks very neat, and is actually in RMAN from 10g Release 1.
I was installing RAC, and during the clusterware install I picked up the wrong interfaces for public and private. What had happened was I had a 10.x.x.x IP on both eth0 and eth1, which was messing up the routing. The solution? Simply modify the VIP in the cluster configuration.