Pythian - Data Experts Blog » Mark Brinsmeadhttp://www.pythian.com/blog
Official Pythian Blog - Love Your DataTue, 31 Mar 2015 18:02:45 +0000en-UShourly1Recent Changes to Oracle SE Licensing Rules: Higher Price?http://www.pythian.com/blog/recent-changes-to-oracle-se-licensing-rules-higher-price/
http://www.pythian.com/blog/recent-changes-to-oracle-se-licensing-rules-higher-price/#commentsFri, 16 May 2008 21:35:31 +0000http://www.pythian.com/blogs/1009/recent-changes-to-oracle-se-licensing-rules-higher-priceRecently, 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 ,  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, 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.1 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.

Here is the new definition, from the current OLSA (revision V050108, last updated 01 May, 2008 it would seem):

Processor:Processor: shall be defined as all processors where the Oracle programs are installed and/or running. Programs licensed on processor basis may be accessed by your internal users (including agents and contractors) and by your third party users. For the purposes 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 , cores shall be determined by multiplying the total number of cores by a core processor licensing factor of .25. For the purposes of counting the number of processors which require licensing for AMD and Intel multicore chips, cores shall be determined by multiplying the total number of cores by a core processor licensing 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 core processor licensing factor of .75. All cores on all multicore chips for each licensed program for each core processor licensing factor listed above are to be aggregated before multiplying by the appropriate core processor licensing 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 an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket.

Yes, they printed the word “Processor” twice. I did not add that. All I have added is the boldface.

Oracle has added 18 new words to the definition of “processor” as it applies to Standard Edition products. Now, a “processor” is a “socket”, but where “multi-chip-modules” exist (note: no definition is provided for that), each chip in the multi-chip module is a “socket”.

So, now you want to license Oracle Standard Edition for a commodity server with 4 quad-core Intel Xeon processors. Your server has only four “physical sockets” (places where you can plug a CPU module into the motherboard), so this everything is good, right?

Not so fast! Intel’s quad-core Xeon processors are (for now, anyway) implemented as Multi-Chip Modules (MCM). Well, at least some of them are. They each contain two processor “chips” or “dies”, each providing two processor cores. So now, each of these CPU modules counts as at least two sockets. The server now has eight sockets, and it is no longer eligible for Standard Edition licenses.

But wait. There’s more. Remember — each chip in the multi-core module counts as a socket. That is what the OLSA says. But exactly how many chips are in this Multi-Core Module? We know there are two processor chips. But there could be other chips in there that we don’t know about (and Intel may not be talking about them either). I tried to find this information on Intel’s website, to my complete dissatisfaction. All I could find was a drawing (i.e., an “artistic rendering”) of what the quad-core Xeon chips look like when you take the top off. The drawing shows two processors dies, as expected, but it also shows nine other smaller “chips” that look like they may be RAM modules. (Makes sense; since we have an MCM anyway, we might as well stuff some extra L2 cache in there, right?)

But whatever the purpose of these “chips”, they are still “chips” — assuming they are actually there. And under the new licensing rules, they are counted as “occupied sockets”, just like all the other chips in the MCM. My hypothetical “cheap and powerful” Oracle database server now has not four “sockets”, but 44 sockets. Even if it was still eligible for Standard Edition licensing, the list price for Standard Edition on this server is now $660,000; a little more than twice the list price for Enterprise Edition on the same hardware.

And it gets even worse! “Multi-core” processors are not the only ones implemented with multi-chip-modules. Multi-chip-modules were considered “innovative” in the 1990s, as we see with this example. Once their advantages became known, it became a relatively common practice to deploy single-core processors (they were pretty much all still single-core back then) like the Pentium Pro and Pentium-II as a multi-chip-modules with a processor chip, an SRAM cache chip, and maybe a memory controller all bundled together in a single package. (This photo of the guts of a Pentium-II seems to show 23 distinct chips inside the module. This article describes a single-core SPARC CPU designed in 1994, packaged as an MCM containing six distinct chips.) There are lots of cost/performance advantages to building MCMs, so I expect that this must still be a common practice even today — such a common practice that it probably isn’t even discussed any more.

Do you know how many chips are in the CPU modules you are using today? Well, if you plan to buy new Standard Edition licenses, is seems that you now need to know!

This just can’t be right, can it? Somebody must have made a mistake. I hope it’s me!

Mistake or not, though, there is a clear moral to this story. You need to read the license agreement, even when you are only planning a purchase. Trust me — reading the license after the P.O.s have been cut will not make you look good in a situation like this. And not reading the license would be a major mistake indeed!

1. Chances are the last hyperlink will not work for you. You may have to go visit the Oracle online store, choose your country of preference, then find and click on the link labeled “License Definitions”.

2. Again, that hyperlink probably will not work for you; if you followed my earlier description to find Oracle’s “License Definitions (Abbreviated)”, you can get a copy of the current OLSA by clicking the hyperlink labeled “Oracle License & Services Agreement” on that page.

]]>http://www.pythian.com/blog/recent-changes-to-oracle-se-licensing-rules-higher-price/feed/40Oracle Configuration Manager: Bane or Blessing?http://www.pythian.com/blog/oracle-configuration-manager-bane-or-blessing/
http://www.pythian.com/blog/oracle-configuration-manager-bane-or-blessing/#commentsFri, 26 Oct 2007 14:52:11 +0000http://www.pythian.com/blogs/644/oracle-configuration-manager-bane-or-blessingI’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.

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…

]]>http://www.pythian.com/blog/oracle-configuration-manager-bane-or-blessing/feed/4Open Letter to Oracle: The Response so Farhttp://www.pythian.com/blog/open-letter-to-oracle-the-response-so-far/
http://www.pythian.com/blog/open-letter-to-oracle-the-response-so-far/#commentsTue, 14 Aug 2007 16:50:39 +0000http://www.pythian.com/blogs/583/open-letter-to-oracle-the-response-so-farAbout 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.

…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.

]]>http://www.pythian.com/blog/open-letter-to-oracle-the-response-so-far/feed/3Postscript to “An Open Letter to Larry Ellison”http://www.pythian.com/blog/postscript-to-an-open-letter-to-larry-ellison/
http://www.pythian.com/blog/postscript-to-an-open-letter-to-larry-ellison/#commentsFri, 06 Jul 2007 21:17:43 +0000http://www.pythian.com/blogs/539/postscript-to-an-open-letter-to-larry-ellisonLast 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:

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.

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.)
What concerns us most is our belief that Oracle Corporation is missing out on a great opportunity to make an excellent product even better. These licensing terms are causing Oracle customers to adopt this otherwise excellent feature more slowly than they otherwise might, if at all. To give a statistically significant example, of Pythian’s 70 outsourced DBA-for-Oracle customers, so few have licensed the use of this feature as to approach zero. We assert that by relaxing the restrictions on accessing the data layer underlying AWR, Oracle may encourage more customers to purchase their “Diagnostic Pack,” the option still needed to access the advanced features of AWR, such as advisors and graphical analysis tools.

We believe that the Oracle database software is the best instrumented database software available. The fact that Oracle already leads the industry in this regard probably led to their decision to make this leap forward in instrumentation an extra-cost item. However, in the interest of making Oracle even better, we would like to invite readers to join us in signing the following open letter to Larry Ellison, CEO of Oracle Corporation. We plan to deliver this letter to Oracle Corporation by courier on July 10, the day before the planned announcement of Oracle 11g.

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/)

N.B. Please join us in signing this letter by placing your name and (optionally) your company affiliation(s), along with the word “SIGNATORY,” in a comment on this blog article. Comments that do not include this word will not be considered signatures.

Please also help by publicizing this open letter on your own blog, on mailing lists, forums or anywhere else Oracle users congregate. We are hoping to achieve a critical mass of signatures by the morning of July 9; the letter will be couriered that day.

]]>http://www.pythian.com/blog/an-open-letter-to-larry-ellison-on-awr-and-ash-licensing/feed/248Silly DBA Tricks 1: Editing the SPFILEhttp://www.pythian.com/blog/silly-dba-tricks-1-editing-the-spfile/
http://www.pythian.com/blog/silly-dba-tricks-1-editing-the-spfile/#commentsThu, 27 Apr 2006 16:56:27 +0000http://www.pythian.com/blogs/179/silly-dba-tricks-1-editing-the-spfileHere 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.