I thought this was an interesting article which breaks down the difference between a Critical Patch Update and Patch Set Updates, with an official word from Oracle included.
http://www.dbspecialists.com/blog/best-practices/patching-your-oracle-database-%e2%80%93-critical-patch-update-cpu-or-patch-set-update-psu/
Thursday, August 30, 2012
Thursday, August 16, 2012
Concurrent:Active Request Limit (or how I finally learned to know what my system was saying)
The other day I saw a few jobs queuing in the Conflict Resolution Manager, and investigating I saw the following message:
This request is pending because the profile option 'Concurrent:Active Request Limit' is set.
This profile option controls how many requests a given user may have running at one time.
User X submitted this request on 09-AUG-2012 08:00:00.
The Conflict Resolution Manager will release this request when the number of running requests for this user is less than the maximum allowed by the profile option.
Now I’d seen this quite a few times but I always thought it was a bug and the CRM thought we couldn’t let anything run, since I interrepted it as being set at a user level, yet today when I looked at the message I wondered if we had it set at a site level and sure enough we did. It is entirely possible that with the old server hardware we were on a few years ago there was a reason this was setup but since it doesn't even look like we're hitting this limit I don’t think we need it set in our environment today since requests appear to be slowed down by this.
This request is pending because the profile option 'Concurrent:Active Request Limit' is set.
This profile option controls how many requests a given user may have running at one time.
User X submitted this request on 09-AUG-2012 08:00:00.
The Conflict Resolution Manager will release this request when the number of running requests for this user is less than the maximum allowed by the profile option.
Now I’d seen this quite a few times but I always thought it was a bug and the CRM thought we couldn’t let anything run, since I interrepted it as being set at a user level, yet today when I looked at the message I wondered if we had it set at a site level and sure enough we did. It is entirely possible that with the old server hardware we were on a few years ago there was a reason this was setup but since it doesn't even look like we're hitting this limit I don’t think we need it set in our environment today since requests appear to be slowed down by this.
Thursday, August 9, 2012
Four words that strike terror in the hearts of men (and women)
After having a major system uplift, there are four words I’ve heard over and over again which are stalking my dreams and turning them into nightmares lately. “We didn’t test that.” Well, that doesn’t seem too dire really, but the repercussions of this are huge and cross every team that worked on the uplift in the first place.
Who is impacted?
Developers - In some cases, these are the unsung heroes of your uplift and what is their reward after it is completed? To keep their noses to the grindstone and work a few more weeks off on the fires that keep cropping up. Doesn’t sound like a real promising job huh?
Projects - Not just the project people, which I'll get back to, but you're now putting off being able to work on your next projects. It doesn't matter if it is old production fixes or currently pipelined new projects, delays will drain your political capital because you are now missing target deployment dates and the business thinks you are pretty much worthless for not catching all the things you are now responsible for fixing. Project personnel start feeling burned out just like your developers because they've been on the project forever, and the bigger the project the longer you'll want to keep them around to play clean up for all the new debris coming up.
Support - How many fires do you get on a daily basis? Multiply that by a factor of 2 or 3 after doing an uplift like this for about a month, and you’ll see what kind of volume you’ll be slowly crushed under when you have people in the new system doing their daily work which they never really replicated in the test environment.
DBAs - During the project and throughout the implementation we've been wearing them thin, and they are now getting no rest by making them look at applying patches and identifying system issues which should’ve been caught months ago so they aren't able to instead be able to focus on things like building new monitoring tools. Fundamental things like missing critical DB bugs can easily happen because everything in the system is being thrown against the wall without a whole lot of investigation possible for each item.
How can we do better?
We need to be more proactive about showing the business and project teams what has been run in the last 30, 60, 180 days in your system and by whom. Having these snapshots would be able to show the majority of the daily, monthly and quarterly reporting goals that the project needs to meet.
We can do a better job about documenting out our system flow, so we know what all our parts and pieces are which are required to provide full service to the business. This way you won't get surprised by a report pushing output to a third party in-house group, to a server you didn't even know was connected to your system.
I'll probably add more as I encounter them, but what would you add to this list?
Who is impacted?
Developers - In some cases, these are the unsung heroes of your uplift and what is their reward after it is completed? To keep their noses to the grindstone and work a few more weeks off on the fires that keep cropping up. Doesn’t sound like a real promising job huh?
Projects - Not just the project people, which I'll get back to, but you're now putting off being able to work on your next projects. It doesn't matter if it is old production fixes or currently pipelined new projects, delays will drain your political capital because you are now missing target deployment dates and the business thinks you are pretty much worthless for not catching all the things you are now responsible for fixing. Project personnel start feeling burned out just like your developers because they've been on the project forever, and the bigger the project the longer you'll want to keep them around to play clean up for all the new debris coming up.
Support - How many fires do you get on a daily basis? Multiply that by a factor of 2 or 3 after doing an uplift like this for about a month, and you’ll see what kind of volume you’ll be slowly crushed under when you have people in the new system doing their daily work which they never really replicated in the test environment.
DBAs - During the project and throughout the implementation we've been wearing them thin, and they are now getting no rest by making them look at applying patches and identifying system issues which should’ve been caught months ago so they aren't able to instead be able to focus on things like building new monitoring tools. Fundamental things like missing critical DB bugs can easily happen because everything in the system is being thrown against the wall without a whole lot of investigation possible for each item.
How can we do better?
We need to be more proactive about showing the business and project teams what has been run in the last 30, 60, 180 days in your system and by whom. Having these snapshots would be able to show the majority of the daily, monthly and quarterly reporting goals that the project needs to meet.
We can do a better job about documenting out our system flow, so we know what all our parts and pieces are which are required to provide full service to the business. This way you won't get surprised by a report pushing output to a third party in-house group, to a server you didn't even know was connected to your system.
I'll probably add more as I encounter them, but what would you add to this list?
Thursday, August 2, 2012
OS Changes - Commands
So we've upgraded from SUN Solaris to RedHat Linux, and I've found some key differences so far. The command prstat no longer really works well to find out how healthy your server/CPUs are, as it needs to be combined with the new top command to get a fuller understanding of how healthy your system is and this site will help you understand why there is a difference between not only the commands but how the OS is operating as well.
To investigate printing issues I grew accustomed to the lpstat command combined with the -lp switches so that a command lpstat -lp PRINTERNAME would give me information as to how the printer was connected to our system and if the printer queue was up or not. I've found out that issuing this command in a RedHat Linux environment doesn't provide that old type of feedback, so we've had to alter our approach and instead use the -a switch so that the entire command looks like lpstat -a PRINTERNAME now.
To investigate printing issues I grew accustomed to the lpstat command combined with the -lp switches so that a command lpstat -lp PRINTERNAME would give me information as to how the printer was connected to our system and if the printer queue was up or not. I've found out that issuing this command in a RedHat Linux environment doesn't provide that old type of feedback, so we've had to alter our approach and instead use the -a switch so that the entire command looks like lpstat -a PRINTERNAME now.
Subscribe to:
Posts (Atom)