Recently, while answering a question, I came across what appeared to be a change to the rules for licensing Oracle Standard Edition — a change that appears to be subtle on the surface, but one that could have significant and surprising repercussions.

It was with considerable fanfare that Oracle announced, several years ago, the last major change to the licensing rules for Standard Edition — that multi-core processors would be counted as a single CPU for the purposes of licensing Standard Edition products. (For Enterprise Edition, Oracle continued to count each core as a separate “processor”, but then provided price discounts, presumably in recognition that a 2- 4- or 8-core CPU rarely provides equivalent performance to an equivalent number of single-core processors running at the same clock rate).

The revised licensing rule went like this (I have highlighted the relevant text in bold):

Processor: shall be defined as all processors where the Oracle programs are installed and/or running. Programs licensed on a processor basis may be accessed by your internal users (including agents and contractors) and by your third party users. For the purpose of counting the number of processors which require licensing for a Sun UltraSPARC T1 processor with 4, 6 or 8 cores at 1.0 gigahertz or 8 cores at 1.2 gigahertz for only those servers specified on the Sun Server Table which can be accessed at http://oracle.com/contracts , “n” cores shall be determined by multiplying the total number of cores by a factor of .25. For the purposes of counting the number of processors which require licensing for AMD and Intel multicore chips, “n” cores shall be determined by multiplying the total number of cores by a factor of .50. For the purposes of counting the number of processors which require licensing for all hardware platforms not otherwise specified in this section, a multicore chip with “n” cores shall be determined by multiplying “n” cores by a factor of .75. All cores on all multicore chips for each licensed program for each factor listed below are to be aggregated before multiplying by the appropriate factor and all fractions of a number are to be rounded up to the next whole number. When licensing Oracle programs with Standard Edition One or Standard Edition in the product name, a processor is counted equivalent to a socket.

This is exactly the definition you will find today today in Oracle’s online store, for example here.¹ In fact, being lazy and not having access to a two-year-old copy of the OLSA, that is exactly where I got the text above.

Now, that little bit of bold text was a pretty big deal. As I understood it, and everybody I could find seemed to agree, this affected both the licensing cost and the eligibility rules. These 23 simple words now meant that Oracle Standard Edition was limited to computers with a maximum capacity of four (4) CPU sockets, not four processor cores. Although multi-core processors were — at the time, several years ago — relatively new, at least in the “commodity hardware” space, we all new that Intel and AMD had near-term plans for 4-core and eventually event 6- and 8-core processors. Suddenly, we could build an Oracle database server with 16 processors (cores) and 16GB of RAM or more, for less than $200,000. (Prior to this change, you would pay $640,000 — list price — just for the Enterprise Edition database licenses.)

But now, it seems, all of this is changing again, only this time, not for the better.

So what exactly has changed? (more…)

I’m not sure how long this has been out there, but there is a new (to me) headline on Oracle’s support website, announcing that next month, they will be phasing out “manual configuration” information for service requests.

Customers are now required to download and install something called Oracle Configuration Manager (OCM), which will gather their system/database configuration information automatically, and forward it to Oracle Support on their behalf.

I don’t know a lot about this tool. Yet. The OCM page on on Metalink offers the following description:

Configuration Support Manager allows you to define computer configurations that describe your Oracle environment, and milestones for projects involving Oracle products. Providing this information will allow you to log SRs with less data entry, track issues more effectively, and will allow Oracle to proactively suggest solutions and resolve issues faster

OCM has been around for a while now, and doubtlessly it does have its uses. For example, I was recently looking for an easy, platform-independent, way of determining the latest CPU update applied to an Oracle home, and OCM popped up right at the top of the list. But, like most DBAs, I’ve been far to busy actually managing databases to really give this tool much thought. Until now, anyway, since it seems I (and you) will have to start using it really soon.

Based on a cursory look and on a few conversations around the office, I gained the impression the OCM is little more than a sophisticated piece of spyware. “Services” like Windows Genuine Advantage spring to mind. You know, “services” that compel you to submit to a scan of your system to establish the validity of your licenses before you can obtain updates or service, and perhaps even threaten to do “bad things“^TM if the scan happens to fail.

I find, though, that upon starting to actually read the OCM documentation (imagine the desperation that motivated that!), OCM does not look quite as scary as it did at first. It still creeps me out somewhat — my vivid imagination has no trouble conjuring up unpleasant images of what Oracle might do with this data once they have it — but the documentation I have read thus far has at least tempered my concerns. Here is what I have found so far:

• Contrary to suggestions I have found elsewhere on Metalink, OCM does not have to report data directly to Oracle support. It does do this when operating in connected mode (the default), but it can also operate in disconnected mode, where collected data is deposited in a .jar file that you can (I hope!) inspect yourself before electing to forward it to Oracle. The availability of disconnected mode makes OCM at least feel less like spyware.

Okay. That’s a short list. But I’ve only just started. I’m sure I’ll find more, right?

Anyway, the option to run in “disconnected mode” makes a fundamental difference here, as it returns control of the conversation from the software vendor back to us, the customers. Providing the data collected is not encrypted (or so horribly obfuscated as to be completely useless), this means that I have the ability to review what is being collected, and decide for myself whether or not I choose to disclose that information and how much I will disclose, or even reuse the collected data for my own purposes.

So, why the big deal? Why am I concerned about letting Oracle support see the “unvarnished” truth about my system configurations? Well, in all honesty, I do find myself telling Oracle support occasional “little white lie”. By nature, I am a very truthful person, but I can imagine legitimate (or at least justifiable) reasons to withhold certain details from Oracle Support. For example, when opening simple support requests, I can understand how a person could comfortably conceal the fact that their test environment runs a binary compatible clone of a supported operating system, rather than the (much more expensive) commercial release. In situations like that, Oracle Support could (okay, maybe legitimately) deny that person service, even though though the problem has no conceivable connection to the fact that their database runs on CentOS rather than Redhat Enterprise Linux.

On the other hand, OCM is a tool that shows considerable potential, much like RDA. I have already imagined a few internal uses for data collected by OCM, but I won’t be writing about those until I take the time to verify that OCM actually collects the data I am after and lets me see it. At the very least, OCM does promise to make it easier for me to open an SR with Oracle support, by removing, I hope, a lot of that routine dialogue I spend 15 minutes completing every time I open a support request.

So, now I find myself completely ambivalent. Or perhaps conflicted. Or maybe simply confused.

Does OCM represent some sort of Orwellian conspiracy, or is it an incredible blessing, unsought and unexpected? I just can’t tell right now. Could it be both? Ooh! My head is starting to hurt just thinking about that one…

About six weeks ago, I wrote, with my colleagues here at Pythian, an open letter to Larry Ellison, imploring him and Oracle to free API-level access to Automated Workload Repository (AWR) and Active Session History (ASH).

This letter has received amazing support from the community, with 158 “signatories” at last count, and many other positive comments.

We received an informal but cordial response from Oracle two or three days after we couriered the letter to them, which said we could expect a formal reply soon.

Sadly, I think the official response was delivered a couple nights ago, with the public release of the Oracle 11g documentation, specifically, “Oracle® Database Licensing Information 11g Release 1 (11.1).” I advise you to read it yourselves, so you can be sure you get the correct information, but I believe that in the section on Diagnostic Pack, we see roughly the same statements as before — API-level access to AWR and ASH continues to require licenses for Diagnostic Pack.

I have only skimmed the entire document; being a slow reader, I’ll need to spend a few hours to read it all. I have noted at least one encouraging item, though. It seems that Oracle has at least provided customers with a means of disabling the AWR features that they cannot or choose not to license.

That is an improvement. Just not the one we had hoped for. That being said, it’ll never be too late for Oracle to do the right thing. And so, dear readers visiting from Oracle, take another look at the comments and signatures again and please re-consider.

I found today’s comment from an employee of a major transnational energy company to be particularly instructive regarding the downside of Oracle’s current strategy. In it, Carl Roberts writes:

…due to these and a few other licensing practises by Oracle we … have made SQL Server our strategic platform.

Sometimes, good tactics can be bad strategy. The signatories and I strongly believe that this is one of those times.

Last week, in collaboration with several of my colleagues here at Pythian, I published an open letter to Larry Ellison. The response to this letter has been — well — surprising, both in volume and in character. It is clear that many in the Oracle community seem to share the sentiments that we have expressed. In fact, we know that we are not alone in this endeavour. Niall Litchfield, for one has run a related online petition for over a year now.

Perhaps the most surprising response came indirectly by e-mail, a note from an Oracle Corp. insider informing us of an upcoming announcement. You can read the details in this note posted by Paul Vallee; and also commented on by Niall Litchfield himself here.

Oracle Corp. surprises me occasionally, and often in a positive manner. This is one of those occasions. They have clearly demonstrated that they are interested in what the user community has to say. I have no illusions that my clumsy “open letter” could possibly be the trigger to this event, as I am sure (or I sure hope) that Oracle’s QA procedures would require some time before even a simple “fix” like this one can be widely released; this must be attributed to the combined efforts of the community at large, and undoubtedly also more than a few complaints registered privately with Oracle Support.

In fact, this is what impresses me. It seems clear that Oracle has been thinking about this for a while, and now they have acted. The fix they have provided is — I think — an important and worthwhile step in the right direction. I still hope that they will continue moving in the right direction, but even if they do not, I feel the need to recognize this improvement.

Accordingly, I plan to append to the “open letter” the postscript that follows the original text:

Dear Mr. Ellison,On behalf of the community, please accept our congratulations on the release of Oracle 11g.

We are writing in the hope that you might seize the opportunity presented by the release of your next-generation database management software to review the licensing policy regarding access to the Automated Workload Repository (AWR) and Active Session History (ASH) features, at least for Oracle 11g.

We believe that AWR and ASH are breakthrough features and represent a leap forward in the already industry-leading instrumentation provided by Oracle. While we fully support your freedom to assess extra license fees for the advanced functions provided through the Diagnostic and Performance Tuning Packs of Oracle Enterprise Manager, we want to give voice to a consensus building among the Oracle user community that Oracle is missing its chance to capitalize on its lead in this area.

We are disappointed by the decision to restrict access, at least using SQL, to the lowest-level tables and views in which performance data, essentially our data, are recorded. Many of us are frustrated by the fact that AWR and ASH collect and retain this data regardless of our wishes, while we are not even able to look at it.

AWR and ASH are integral parts of Oracle, which is why there are no effective means of disabling them. They are even built in the Standard Edition, for which no way to license them exists. Consequently, Oracle customers are exposed to substantial licensing liabilities (since according to the licensing terms even a single accidental query of the data would entail a requirement to upgrade to the Enterprise Edition plus the Diagnostic Pack).

We believe that changing the licensing terms to allow customers to access the basic data in the tables and views underlying AWR and ASH would actually benefit Oracle’s sales by making Oracle databases substantially better instrumented and thus easier to manage than those built using any competitor’s RDBMS. This would also encourage customers to adopt the basic features of AWR and ASH and eventually become more likely to consider the advantages of licensing the more advanced features accessible through Oracle Enterprise Manager.

We hope that with this successful release of Oracle 11g your licensing team at Oracle Corporation will consider revising the licensing terms to allow us to access at least the lowest-level views and APIs of AWR and ASH in your current release. We believe that making this licensing change effective with the 11g release will assure that the rate of adoption of 11g will be substantially more rapid than otherwise because there is more pent-up demand for this feature today among Oracle performance enthusiasts than for any other in Oracle. In so doing, you will also make us more confident of our ability to assure our respective managements that we comply with with our Oracle licensing terms.

Yours truly,

Members of Oracle user community
(signed electronically at http://www.pythian.com/blogs/526/)

P.S.: We see that since the publication of the first draft of this letter, Oracle Support has provided, in metalink note 436386.1, a means of resolving at least some of our more fundamental concerns regarding license compliance. We welcome this as a clear step forward, but continue to hope that you will consider the advantages of freeing us to use the data-level APIs for AWR and ASH, and that you see the mutual benefits this might bring.

As we are approaching 100 signatories to the letter, I would like to make one last push to get to 150 signatures by Monday when the letter must be printed and fedexed. Please post a comment to the open letter with the word SIGNATORY and let your voice be heard.

Please note this late-breaking news related to this story. Then still please sign our letter!

15 years ago, with the release of Oracle 7.0.12, Oracle gave the world—or at least its customers—something really great: the Oracle Wait Interface (OWI).

The OWI is one of the reasons that Oracle’s database product and its customer base are what they are today. It provides a clear, transparent, and above all useful view of what the database is doing and where it is spending its time. This level of instrumentation has allowed Oracle customers to not only tune their databases and applications but also to understand them.

Most importantly, this instrumentation was stored in performance views that were accessible by SQL so that tuning techniques could be invented and refined using the data that the wait interface provides. The wait interface revolutionized Oracle performance tuning, massively increased Oracle users’ ability to scale applications, and enabled Oracle to dominate the world-wide-web revolution thanks to the users’ new ability to genuinely understand the performance characteristics of their applications.

Over time, performance tools evolved from BSTAT/ESTAT reports to Statspack, both provided by Oracle to interpret OWI data. SQL tracing and session profiling using TKPROF and other utilities were the next tools that DBAs turned to, and they allowed an even deeper understanding of the functioning Oracle database. Neither the OWI data nor the interpretation tools were separately licensed. And in 10g, Oracle released Automated Workload Repository (AWR) and Active Session History (ASH), a revolution in the level of instrumentation provided by the database. However, Oracle decided to separately license both the data collected in the performance views and the interpretive tools in OEM. As a result, the true power of AWR and ASH have yet to be unleashed.

AWR and ASH boast a number of very useful capabilities already covered in great detail elsewhere. Unfortunately, the majority of Oracle customers have never been able to use even the most rudimentary capabilities because of licensing restrictions. In fact, these restraints not only prevent the majority of Oracle users from accessing AWR and its underlying data but they also leave customers with no supported means of turning AWR off.

(If you’re not already familiar with these restrictions, you can read about them in the Oracle 10g Licensing Information Manual, here, here, and many other places.)
(more…)

Here is an article I posted on the Oracle-L mailing list recently. Much to my surprise, people liked it enough that they asked to see it here, too.

This was written in response to the question: “How do you edit an SPFILE?”

—————————————————

There are lots of ways to do this — some supported; most not.

The supported ways basically amount to one of

• CREATE PFILE=… FROM SPFILE
• ALTER SYSTEM SET xxxx = yyyyyyyy SCOPE = SPFILE

I would normally recommend you stick to one of these.

If you insist on editing an SPFILE, you can, (I have done so successfully on a couple occasions) but it is a very bad idea(tm). The first thing to know is this:

• The documentation says SPFILEs are “binary” files.
• The documentation is only half-true.

In actual fact, the SPFILE is really just a simple text file, with binary (ASCII NUL) padding at the beginning and end. On a UNIX(-like) system, you can create a perfectly valid PFILE from any SPFILE with the command:

$ strings spfileMYSID.ora > initMYSID.ora

You *can* also edit it directly, providing you have a binary-capable editor (e.g., “emacs”). Forget editors like ‘vi’ — the standard ‘vi’ editor does bad things to binary files, like replacing ASCII NULs with spaces. Since SPFILEs use ASCII NUL for padding… (note: the Linux version of ‘vi’ — actually “vim” — probably doesn’t do this. Others may not any more, either. I wouldn’t know; I stopped trying to use ‘vi’ to edit binary files about 15 years ago.)

If you insist on editing your SPFILE, I have found that balancing my edits by adding or removing characters from the NUL padding at the end of the file works quite nicely. Of course, I’ve only actually done it about twice. The fact is, there are enough safe (and supported!) alternatives that you should never have to do this.