What is actually in the box, what costs extra, and the features that enable themselves: the option price list, the permanent usage record in DBA_FEATURE_USAGE_STATISTICS, the EE versus SE2 decision, and the five step governance loop. One 8 license database, priced with its real option stack: $572,000 at list, $1.2M over five years.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
A taught session with three knowledge checks: the AWR report question (the most common audit finding in the Oracle world), the option stack arithmetic, and the audit scenario where old usage meets an audit letter. It ends by pricing one database's real bill: base plus three options, $572,000 at list and $1.2M over five years.
The full narration of this session, section by section, for reading and reference.
Welcome back, session three of forty. Last time you learned to count, cores, users, minimums, the fifty user breakeven. Today we answer the other half of the question: what exactly are you counting? Because here's the uncomfortable truth about Oracle's database. The thing you install is not the thing you bought. The installer puts everything on the server, the base edition and every priced option and pack, no license keys, no unlock codes, nothing separating what you own from what costs twenty three thousand dollars a processor. And the database quietly writes down every feature anyone ever touches. That's the options trap, and it's where two thirds of most database spend, and most audit findings, actually live. Three knowledge checks as always, and one of them is the single most common audit finding in the Oracle world. Thirty minutes. Let's open the box.
Five things you'll take away today. One, you'll be able to read the box, what Enterprise Edition actually includes for its forty seven and a half thousand, and what sits on top as a separate purchase. Two, you'll know the option price list, the big numbers, RAC, Partitioning, the packs, and the multiplication rule from session two that makes them explosive. Three, you'll understand the trap mechanically, how options enable themselves and how the database records usage forever. Four, you'll be able to run the edition decision, EE versus SE2, on actual requirements instead of habit, because habit is expensive. And five, you'll leave with a governance loop, five steps, quarterly, that keeps your option usage matched to your entitlements, which is the entire difference between an audit finding and a quiet internal fix. Let's start with why this deserves a full session.
Four numbers. First, two thirds. In a typical estate, roughly two thirds of the database spend is not the database. It's the options and packs stacked on top. When people budget for Oracle they picture the base license; the base license is the visible third. Second, twenty three thousand dollars. That's the list price, per processor, for Real Application Clusters. Also for Database In-Memory. Each. On top of the forty seven five base. Options aren't accessories, some of them cost half a database. Third number, zero. That's how many license keys, activation codes, or purchase checks stand between a DBA and any priced option. Everything installs by default and simply runs. The purchase decision and the technical decision are completely disconnected, and Oracle likes it that way. And fourth, same. As in, same metric, same count as the database underneath, the rule from session two. License the database on eight processor licenses, and every option it runs needs eight too. Which means every counting mistake you could make in session two multiplies through every option in session three. The base edition is the cover charge. The options are the bill.
So what's actually in the box? Five layers. Layer one, what EE includes. The core database engine, obviously, plus a decent set of included capabilities, basic Data Guard for standby, basic compression, online operations. Paid once, inside the forty seven five. Layer two, what SE2 includes, a genuinely capable subset living inside the fence from session two, two sockets, sixteen threads, and, critical point, no options attachable at all. You cannot buy Partitioning for SE2. Layer three, the options. RAC for clustering, Partitioning for large tables, Active Data Guard, In-Memory, Advanced Security. Each one a separate line item, priced per processor. Layer four, the management packs, Diagnostics, Tuning, Lifecycle. These are the features behind Enterprise Manager's most useful screens, and they're where the most innocent looking finding comes from, hold that thought for the first knowledge check. And layer five, the free tier, Express Edition and developer licenses, fine for a sandbox, never for production, never for DR. Here's the design flaw you have to internalize: all five layers arrive in one installer, and nothing on the screen tells your DBA which side of the invoice a feature sits on. The software has no price tags. Your governance is the price tag.
Let's put real numbers on the big ones, and I'll use the eight processor license database from session two as the multiplier, because that's how these prices actually land. RAC or Database In-Memory, twenty three thousand per processor. On our eight license database, one hundred eighty four thousand dollars. Each. Advanced Security, fifteen thousand, so a hundred twenty thousand on that database. The eleven and a half thousand tier, Partitioning, Active Data Guard, Advanced Compression, ninety two thousand each. And the packs look cheap by comparison, Diagnostics at seventy five hundred, Tuning at five thousand, until you notice that's another hundred thousand across the pair on one database, and packs tend to be enabled everywhere. Two rules travel with every line. NUP pricing is one fiftieth of each figure, exactly like the base edition, the session two ratio holds across the entire price list. And support, twenty two percent of net, applies to every one of these lines, every year, forever. An option isn't a purchase, it's a subscription you can never quite cancel. Now, the most common way one of these lines appears on an audit finding. Knowledge check one.
Knowledge check one. A DBA is troubleshooting a slow query. They open Enterprise Manager, pull up an AWR performance report, find the problem, fix it, everyone's happy. What just happened, licensing wise? A, nothing, performance views are part of Enterprise Edition. B, they used the Diagnostics Pack, a separately licensed product, and the usage is now recorded. C, it only counts if they export the report. Or D, OEM is free, so anything inside it is free. Pause here, and think about which layer of the box AWR lives in.
The answer is B. AWR, the Automatic Workload Repository, ASH, and the performance screens built on them belong to the Diagnostics Pack. Seventy five hundred dollars per processor, licensed for every processor of every database it touches. And the moment that report ran, the database wrote the usage into its own feature tracking views, with a timestamp, permanently. Now look at the wrong answers, because they're all things real DBAs believe. A confuses the included basic views with the pack, and the line between them is genuinely obscure, that's the trap working as designed. C invents a rule, use is use. And D has it exactly backwards, the Enterprise Manager console is free, but its best screens are a vending machine for priced packs, and, here's the kicker, the setting that controls pack access ships enabled. This finding, packs used without licenses, is arguably the most common item on Oracle audit reports, not because DBAs are careless, but because the product is engineered so the helpful path is the licensed path. Which raises the question: how does the recording actually work? Next slide.
How usage gets recorded, four facts. Fact one, the database keeps score on itself. There's a view, DBA underscore FEATURE underscore USAGE underscore STATISTICS, write that one down, it's the most important database view in this entire course, and it logs every priced feature ever exercised, with first use, last use, and counts. When Oracle's audit scripts run, this is precisely what they read. The evidence isn't gathered by the auditor, it's been gathered for them, by your own database, for years. Fact two, one action is enough. Create one partitioned table, run one compressed backup test, open one AWR report, and the flag sets. The view doesn't record intent, doesn't distinguish an experiment from production use. First use is use. Fact three, the defaults do the enabling. OEM ships with pack access on. The installer includes every option. Some features engage as side effects of perfectly routine administration. Nobody in your organization ever decides to start using an option; the estate drifts into usage by default. And fact four, the one that changes behavior: history does not erase. Disabling a feature stops future use. The recorded history stays right where it is, and the audit conversation is a conversation about history. Let's make sure the arithmetic of that conversation is solid. Knowledge check two.
Knowledge check two, calculator optional. An eight processor license Enterprise Edition database is running three extras: Partitioning, the Diagnostics Pack, and the Tuning Pack. Per processor, those list at eleven thousand five hundred, seven thousand five hundred, and five thousand. What do the three add at list, before support? A, about ninety two thousand. B, about a hundred ninety two thousand. C, about three hundred eighty four thousand. Or D, nothing, if the features aren't actively used anymore. Pause and run it.
The answer is B, about a hundred and ninety two thousand dollars. Eleven five plus seven five plus five is twenty four thousand per processor, times eight licenses. And put that next to the base: the database itself was three hundred eighty thousand, so three modest options just added half the base price again. That ratio, options adding fifty to a hundred percent on top, is completely normal, it's how two thirds of estate spend ends up in options. A priced only the Partitioning line, C doubled the count, check whether you multiplied by sixteen somewhere. And D. D is the answer I actually care about, because it's the one people argue in real audits. The obligation follows recorded usage, and we just established the history doesn't erase. Stopping use reduces your future exposure and strengthens your negotiating story, it does not zero the finding. If D tempted you, replay slide eight after this session. Now let's zoom back out to the edition decision, because options are half of that choice.
EE versus SE2, decided properly this time. Session two gave you the price gap, thirty five thousand versus seven hundred sixty thousand on the same server. Today you can see what the gap actually buys, and the decision rule falls out cleanly. EE is mandatory when you genuinely need an option. Real clustering with RAC. Partitioning on billion row tables. Active Data Guard for a readable standby. The security options for regulated data. Notice the shape of that sentence: the option need decides the edition, not the other way around. SE2 wins when the workload fits the fence, two sockets, sixteen threads, no options required, and the growth path is understood. At a twentieth of the cost, respecting that fence is one of the highest paid activities in IT procurement. And then there's the middle, and the middle is where the money leaks. A large share of EE databases in real estates run zero options in production. Zero. Every one of those is paying roughly thirty thousand dollars per socket of premium for headroom nobody planned or measured. Those databases are your SE2 migration candidates and your renewal negotiation ammunition. Mixed estates are normal and healthy, EE where options earn it, SE2 where the fence fits. The discipline is documenting which is which, and why.
Here's the governance loop, five steps, run quarterly, and I want to sell you on how cheap this is. Step one, inventory. Run the feature usage view on every database. It is literally one query per instance, a DBA can script the whole estate in an afternoon. Step two, map. Line the recorded usage up against what your ordering documents say you own. Options showing usage that you don't own, circle them. Options you own showing no usage anywhere, circle those too, that's shelfware for the renewal conversation. Step three, remediate. Disable what's unowned and unneeded. Drop the partitioned objects, turn off the packs, document the date. Step four, lock. Set the OEM pack access control to match your actual licenses, and strip options out of your standard install images so the next server starts clean. And step five, recheck, quarterly, because one database restore, one vendor script, one enthusiastic new hire can re-enable anything. Here's the economics of this loop. Finding your own usage first turns a list price audit claim into either a quiet internal fix or a planned purchase you negotiate at a discount, on your timeline, with your leverage. The loop costs a few DBA hours a quarter. The findings it prevents are priced in the hundreds of thousands. There is no better return in this course.
The five option traps, the specific ways these findings are born. Trap one, the default install. Every option ships in the standard installer, so the decision to deploy a database was never a decision about options, but the audit treats the server as fully armed. Standard images that strip or lock options fix this at the source. Trap two, the OEM checkbox. Management pack access ships enabled, so every administrator who clicks the pretty performance pages is consuming the Diagnostics Pack. One setting, checked once, ends it. Trap three, the helpful script. Vendor tools and internal automation that create partitioned tables or compressed objects, exercising options nobody chose. The usage view doesn't record who meant it. Trap four, the dev copy. Full EE installs scattered across developer machines and test rigs. Developer license rights are much narrower than people assume, and test and DR environments count like production, session two's lesson, still true here. And trap five, the false clean up. We disabled it, so we're fine. You know why that fails now, the history stays, and the conversation is about the history. The pattern across all five: nobody decided anything. The estate drifted. Which is why the governance loop exists, and why the last knowledge check is about what happens when drift meets an audit letter.
Knowledge check three, and this one is a scenario straight from real life. An Oracle audit finds that Partitioning was used two years ago, on a table that was dropped last year. Nothing partitioned exists today. Oracle claims eight processor licenses of Partitioning at list, ninety two thousand dollars, plus back support. What's your position? A, no exposure, the feature isn't in use today. B, the claim has a basis in the recorded history, and the defense is remediation evidence plus negotiating the resolution, not denial. C, pay the claim, recorded usage means list price is automatically owed. Or D, delete the usage history and close the finding. Pause. Think about what the history proves, and what it doesn't.
The answer is B, and the reasoning matters more than the letter. A fails on the facts, the obligation attaches to use, the use is recorded, current state doesn't erase it. But C overcorrects into the opposite mistake. Audit claims open at list, and they resolve as negotiated commercial outcomes, routinely far below the opening number, and a claim like this one, old usage, remediated, clean current state, documented governance, is exactly the kind that shrinks dramatically or folds into a broader deal. Paying the opening number is donating money. And D. Deleting evidence during an audit converts a licensing dispute into a genuinely serious legal problem, spoliation, breach of the audit clause, the kind of thing that ends careers. It's the only answer on the slide that can make things worse than paying list. So the position is B: acknowledge the history to yourself, marshal your remediation evidence, and treat the number as an opening bid. Module five choreographs this entire dance across five sessions. Today just set the posture: never deny, never panic pay, always negotiate from documented facts. Alright, let's total up today's arithmetic on one screen.
The same eight license database from session two, now with its real bill. Base Enterprise Edition, eight times forty seven five, three hundred eighty thousand at list, eighty three and a half thousand a year in support. Now the three extras from knowledge check two, Partitioning, Diagnostics, Tuning, twenty four thousand per processor, one hundred ninety two thousand, and their own forty two thousand a year of support. So the real database, the one that actually runs in production with the features your team actually touches, is five hundred seventy two thousand dollars at list, carrying a hundred twenty five, hundred twenty six thousand a year in support. And now the line that reframes the whole conversation: hold it for five years, license plus five years of support, and you're at one point two million dollars. For one database. Three modest options turned a three eighty purchase into a seven figure commitment, and remember, these were the mid priced options, we never touched RAC or In-Memory at twenty three thousand each. This is why I said the options conversation is the cost conversation. Discounting the base edition while ignoring the option stack is negotiating a third of the bill.
Session three in three sentences. One, everything ships in one installer, and nothing in the software separates the included features from the ones priced at up to twenty three thousand dollars per processor, the price tags exist only on paper you've probably never cross referenced. Two, usage is recorded permanently on first use, Oracle's scripts read that history, and disabling a feature stops the future without erasing the past. Three, the governance loop, inventory, map, remediate, lock, recheck, costs one query per database per quarter and converts audit findings into internal corrections, it's the single best return in this course. And carry forward the five year number: one database, five seventy two at list, one point two million over five years. Next session is the big one we've been flagging since session one, virtualization and partitioning. The VMware question. How one small database on one small VM becomes a claim against every core in your datacenter, why that claim rests on a document you never signed, and the architecture playbook that shrinks it by ninety percent. It's the largest number in most Oracle audits, and after Tuesday it won't surprise you. See you there.
Homework, about an hour, and this week it produces the most valuable single artifact so far. One, run the query. Ask a DBA to pull DBA FEATURE USAGE STATISTICS from one production database. Ten minutes of their time, and what comes back is your own private audit preview, the exact evidence Oracle would read. Two, compare it to paper. Options showing usage versus options on your ordering documents. Circle every mismatch, in both directions, unlicensed usage is exposure, licensed non usage is negotiation ammunition. Three, check the checkbox. Find the management pack access setting in your OEM. Note what it's set to, and try to find out who decided. My prediction: nobody decided. Four, count the editions. How many of your EE databases run zero options? Each one is a candidate for SE2 or for the renewal conversation. And five, save everything. Date it, file it next to session two's server pricing drill. You are, quietly, three sessions in, building the standing license position that module five will turn into an audit defense. That's the hour. It might be the most valuable hour in the whole course.
Five reads to go deeper, all free on redress compliance dot com. First, hidden Oracle audit risks, the findings estates never see coming, and options sit right at the top of that list. Second, challenging Oracle audit findings, how option claims like our knowledge check three scenario actually get contested and resolved. Third, interpreting LMS script output, this one shows you the exact views Oracle's scripts read, including the feature usage tables we met today, read it next to your homework output. Fourth, conducting internal Oracle license audits, the governance loop from today expanded into a full standing program. And fifth, how to fight an Oracle audit claim, your preview of module five, from opening claim to negotiated outcome. That's session three. You know what's in the box, what it costs, and how the evidence works. Next time, the cluster question. Bring your VMware architecture diagrams if you can get them, because we're going to run Oracle's math against them, live. See you in session four.