Kerry Osborne's Oracle Blog

I went to the Dallas 100 awards banquet last night. The Dallas 100 is an annual award for the fastest growing privately held companies that are based in the Dallas / Fort Worth area. Enkitec was ranked 42nd in our first year to be eligible. They have it every year at the Morton Meyerson. It’s a beautiful place by the way, with one of the worlds greatest pipe organs.

Ray Hunt was the speaker. He had a couple of insightful things to say (of course I’ll have to paraphrase).

He said the oil business was the only business he was aware of where you could look forward at the first of every year and know that 90% of the decisions you’ll make that year will be wrong. Which means that the other 10% have to make up for all those wrong decisions and still provide a reasonable profit to the business. He said his background in the oil business made him very tolerant of failure and that America in general was very tolerant of failure which he thought was a good thing. He then told a story about one of his managers telling him that his department had not made any mistakes in the previous 12 months. To Ray that meant one of two things (and both were bad). Either the manager had lost complete touch with reality, or his department was not being aggressive enough.

He went on to list his top 5 attributes of successful companies. He said he thought the most important characteristic of a successful company was it’s Culture.

He defined Culture as the combination of the shared values and the shared work ethic of a group of individuals.

Other attributes that made his top 5 list were:

• Adaptibility – the ability to change
• Agility – the ability to move quickly
• Differentiation – the ability to recognize, retain, and enhance that which sets you apart
• Contrarian – the ability to question the accepted practices

Here’s a very brief story in response to Doug Burns’ post at his blog calling for stories on Human Error.

My very first job out of college was with a large oil company that had Oracle running on bunch of VAX/VMS systems. We had a lot of code written in FORTRAN with OCI calls (this was back in the early 80’s, so no pre-compilers yet). I was working late one night from home, which in itself was an unusual thing because not too many people were able to work remotely at that time. We only had 1200 baud modems for crying outloud, so it was painful to do much of anything remotely. At any rate, I was working on a program with some kind of iterative processing which took a while to complete. So I’d make a few changes and run it, make a few changes and run it. Well I noticed that the execution time slowed down somewhat and so I went looking to see what else was running on the system. (brief digression: I had become a neophyte sys admin due to my being the Oracle DBA and needing to have some system privileges for doing upgrades and whatnot) So I had a look to see what might be slowing my program down and sure enough there was a batch job running that was really using a lot of cpu. Well I had learned about the ability of VMS to set process priorities and so I thought to myself, “that batch job has all night to run it shouldn’t be slowing me down right now”. So I determined to change the priorities so my program would not be competing so heavily with the batch job. Unfortunately, instead of lowering the priority of the batch process, I jacked the priority of my process way up. (you’ll see why I say “unfortunately” in a minute) So anyway, the priority change worked out great. My program executions began running even faster than they had prior to the batch job kicking off. So I went back to my programming routine. Make a few changes, execute the program, check the results, make a few changes, execute the program, check the results… until I executed the program and it didn’t come back. I remember thinking, “Uh oh, I think I messed up the check for getting out of that loop”. So I thought, “well I’ll just ctl-C out and fix it”. Unfortunately, in a stupendous example of Murphy’s Law,  it was at just this point that my modem lost it’s connection. Great! So I tried to reconnect. The modem was able to establish a connection, but the machine was so busy running the process with the insanely high priority that it didn’t have enough spare CPU to log another process in. (Unlike most systems today, VMS had a very hard priority system. The process with the highest priority basically stayed on the CPU as long as they wanted – oh and by the way, there was only the one CPU) So anyway, the program ended up running most of the night and only stopped because it filled up the disk with a log file that it was writing. Needless to say, the real sys admins were not too happy with me the next morning when I showed up at work.

The best Oracle conference in the galaxy.

I’ve attended the last 4 years in a row and I have to say that it’s been far and away the best conference or training event that I’ve ever participated in. Add to that the extremely high quality of the people in attendance and you get an awesome event. 

The 2009 Symposium will be held in Dallas (as always), March 8-12. Chris Date will be giving the key note address. He is one of the founding fathers of Relational Databases and I am very interested to hear what he has to say. 

I must say I am extremely honored to be able to present at this years symposium, and humbled to be in the company of the other presenters. Here’s a link to the speakers page for this years event. And here’s a link to the sign up page.

Hope to see you there!

Oracle uses the BITAND function heavily (over 1000 times in the catalog.sql script alone as of 10.2.0.4). It’s used to determine whether a particular bit is set or not.

Here’s a link to 11gR1 documentation on the BITAND function. The function takes 2 arguments and performs these basic steps:

1. Converts the 2 arguements to binary (n-bit two’s complement binary integer value)
2. Performs a standard bitwise AND operation on the two strings
3. Converts the binary result back to decimal

So what’s a standard bitwise AND operation actually do?

Well it basically does a logical AND of two bit strings. If the values in any position are both 1’s, then the result will have a 1 in that position, otherwise the result will have a 0 in that position. Here’s a link to the Wikipedia entry on bitwise operations in case you want more information.

Here’s an example:

   
    0101
AND 1001
  = 0001

Continue reading ‘Oracle BITAND function (bitwise AND)’ »

There is a fair amount of information available on this topic already, but I thought I’d add my two cents worth here.

So why might you need to do this in the first place? Well generally it’s because some parameter has been set that someone later decides was a mistake. Or, as in my case, because Oracle comes out with a new way to handle a parameter making it attractive to let Oracle automatically handle it. db_file_multiblock_read_count is just such a parameter, but I’ll have to save that for another post. Anyway, there are a couple of key points to keep in mind:
 

1. Oracle does a lot of things automatically (if we don’t prevent it)
2. Some of the automatic things are good
3. Setting a parameter back to it’s default value IS NOT THE SAME as unsetting it

 
But first a few house keeping basics. Oracle has a view called V$PARAMETER which lists all the non-hidden parameters, their current values and a few fields which indicate whether the current value has been altered from the default value (ISMODIFIED and ISDEFAULT in particular). The view is based on X$KPPI and X$KSPPV. These X$ views contain the so called hidden parameters (those beginning with “_”) as well as the regular init.ora / spfile parameters, although the V$PARAMETER view doesn’t expose the hidden ones. There is a metalink note with all the fixed view definitions by the way (220021.1). But it’s easier just to pull the definition from V$FIXED_VIEW_DEFINITION (fixed_view_def.sql) and you’ll be sure you have the version that you’re actually running. Here is a link to the 11gR1 doc on the V$PARAMETER view.

One of the things that has always bugged me about the V$PARAMETER view is that the ISDEFAULT column is not updated when a parameter is dynamically changed. There’s another column, ISMODIFIED, that is changed when a parameter is changed with an alter system or alter session command. But it’s a pain to have to look at two columns. So I wrote this little script (parms.sql) to make it a little easier to deal with. It also displays hidden parameters if you ask for them. It’s based on the 10.2.0.4 definition of V$PARAMETER but it works in 9i and 11gR1 as well.

Continue reading ‘Reset Oracle init.ora / spfile parameters’ »