The map for the whole course: five product families and their five rulebooks, the contract stack and what actually binds you, the two metrics that carry most of the money, the license lifecycle, and the five findings that appear in nearly every Oracle audit. Three knowledge checks along the way, so have a pen ready.
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.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. The three checks in this session cover the contract stack, the core factor arithmetic, and audit finding severity.
The full narration of this session, section by section, for reading and reference.
Alright, welcome in. This is Oracle Licensing Mastery, session one of forty. So here's the deal. Over the next twenty hours, we're gonna take apart the entire Oracle relationship, piece by piece. The licensing rules, the contracts, ULAs, support renewals, audits, the cloud, Java, all of it. Now, I've spent my whole career sitting on the customer's side of the table in these negotiations. So fair warning, this course has a point of view. Yours. And here's how these sessions work. I teach, and then I check. Three times today I'm gonna put a question up on the screen with four options, and I want you to actually pause and commit to an answer before I give it to you. That's not busywork. Picking an answer, even a wrong one, is what makes this stuff stick. Today though, today is just the map. Five big ideas, thirty minutes. Let's get into it.
So here's what you're walking away with today. Five things. First, the estate. Oracle isn't one product, it's five product families, and every one of them plays by a different rulebook. By the end of today you can name all five. Second, the paper. You'll know which documents actually bind you, and which ones are just, well, PDFs Oracle publishes on their website. Honestly, that one distinction is worth the whole course. Third, the two metrics that carry most of the money, Processor and Named User Plus. Not the full math yet, that's session two, just how they work. Fourth, the lifecycle. A license gets bought, deployed, supported, audited, renewed, and money leaks at every single stage, always in the same direction. And fifth, the traps. Five findings show up in almost every Oracle audit. Five. Once you know them, you can't unsee them. Okay. But first, let me convince you this is worth caring about at all.
Four numbers on the screen. Let me walk you through them. Forty seven and a half thousand dollars. That's the list price for one, single, processor license of Oracle Database Enterprise Edition. One license. And that's before the options, things like Partitioning or RAC, which are priced separately, on top, per processor. So a fairly ordinary cluster can carry seven figures of list price exposure. And nobody notices, because nobody's adding it up. Second number, twenty two percent. Every year, Oracle charges twenty two percent of what you paid for your licenses, as support. Think about that for a second. In under five years, you've bought your licenses twice. And that support number is engineered, and I mean engineered, to never go down on its own. Third, the uplift. Lately Oracle's been adding eight percent or more per year on top. Compound that for a decade and support quietly becomes the biggest line in the whole relationship. And the last number is five. Five recurring audit findings drive most of the compliance pain out there. Not fifty. Five. You'll know every one of them in about fifteen minutes. So no, this is not IT admin trivia. For most big companies, Oracle is one of the largest unmanaged financial exposures they have. Unmanaged, because it looks technical. It's not. It's money.
Okay, let's map the estate. When people say Oracle, they usually mean the database. But a real enterprise Oracle relationship is five families, and, this is the key part, each one runs on different rules. Family one, the database and its options. Enterprise Edition, Standard Edition Two, and that long menu of separately licensed options and packs. This is where most audits live, because the software's everywhere and the counting rules are, let's say, subtle. Family two, middleware. WebLogic, analytics, integration tools. Middleware has this habit of being installed way more widely than anyone remembers buying it, because it ships underneath other products. Family three, the applications. E-Business Suite, JD Edwards, PeopleSoft, Siebel. Old, huge, and carrying support bills that have been compounding for twenty years. Family four, Java. And Java gets its own warning label. Since twenty twenty three, Oracle prices Java by your total employee count. Not users. Employees. All of them. It's the fastest growing audit campaign Oracle runs right now. And family five, cloud. Which is really two things, OCI infrastructure credits, and the SaaS apps like Fusion and NetSuite. Different contracts, different renewal games. So, quick gut check. How many of these five does your company run? For most of you it's at least four. Four rulebooks. And usually one person who's supposed to know them all. That person is about to be you.
Now, where are the rules actually written? This might be the most important slide of the day. The Oracle contract stack. Three layers that bind you, and one that just pretends to. Top of the stack, the Oracle Master Agreement, the OMA. Or if your relationship's older, an OLSA. That's the framework. Definitions, the audit clause, territory, assignment. You signed it years ago and I'd bet money nobody's read it since. We fix that in module two. Under that, the ordering documents. One per purchase. This is where the money lives. What products, what metric, what quantity, what price, and any special terms your predecessor was smart enough to negotiate. When there's a fight about what you own, the answer is on an ordering document. Then the Technical Support Policies. These get pulled into your contract by reference, and, here's the kicker, Oracle updates them over time. They hold the rules that make support so sticky, like matching service levels. And then, the bottom row. The policy papers. The partitioning policy. The cloud licensing policy. Listen carefully. You never signed these. They're documents on Oracle's website. Contractually? They decide nothing. In an audit? Oracle will wave them around like they're the law. So here's the habit I want you to build, starting today. Whenever anyone tells you what you must do, Oracle, an auditor, anyone, you ask one question. Which signed document says that? That question is going to follow us through all forty sessions. And speaking of which, let's see if it stuck. First knowledge check, coming up.
Alright, question one. Here's the scenario. You're in an audit. The auditor says, per the partitioning policy, you need to license every host in your VMware cluster. And they sound very sure of themselves. So, what actually decides what you owe? Option A, the partitioning policy on oracle dot com. Option B, the Technical Support Policies. Option C, your signed OMA and ordering documents. Or option D, the output of Oracle's LMS audit scripts. Pause the video. Actually pick one. I'll wait.
Okay. If you picked C, your signed OMA and ordering documents, that's the one. Here's the why, and the why matters more than the answer. Only signed documents create obligations. That's just contract law. Option A, the partitioning policy? Never signed it. It's guidance. It's Oracle's opinion about your money. Option B, the support policies, those are real, but they govern support pricing, not what you owe for licenses. And option D, the audit scripts? Scripts measure things. Measurement isn't obligation. The script can say you installed something, it cannot say what that costs you. Only the contract does that. Now, don't get me wrong, in the room, the auditor will lean on that policy hard, and module five teaches you exactly how that fight goes. But your anchor, always, is the signed paper. If you got this one right, you've already absorbed the most important idea in the whole session.
Now let's talk money mechanics. Two metrics carry most of the spend, Processor and Named User Plus. Processor counts hardware. You take the physical cores where the software runs, and you multiply by a core factor from Oracle's table. Most Intel and AMD chips, that factor's zero point five. So sixteen cores times zero point five, eight processor licenses. Easy, right? On one physical box, sure. The trouble starts with clusters and VMs, where Oracle's soft partitioning position can blow that count up from one server to the entire cluster. That's next session, and honestly, it's a big one. Named User Plus flips it around. You count people and devices instead. Every individual, every device, that accesses the database. And here's the part everyone misses. Including indirectly, through other systems. So if ten thousand people use a web app, and that web app talks to your Oracle database, congratulations, that's ten thousand named users. That's called multiplexing, and it's why NUP on anything internet facing is a trap. Oh, and there's a floor. Enterprise Edition requires at least twenty five named users per processor, whether those people exist or not. Run the numbers and you'll find the minimum decides the price more often than your actual headcount does. Big takeaway for today, the metric isn't a technicality. Choosing it well is one of your first real pieces of leverage. Let's test the arithmetic. Question two.
Question two, and this one has actual math in it. A server runs Database Enterprise Edition on sixteen Intel cores. Core factor, zero point five. Two parts. How many processor licenses does it need? And if you licensed it by user instead, what's the Named User Plus minimum? A, sixteen licenses, or twenty five named users total. B, eight licenses, or a two hundred named user minimum. C, eight licenses, or twenty five named users total. D, thirty two licenses, or eight hundred named users. Pause here, and actually do the arithmetic. It's two multiplications, you've got this.
So, the answer is B. Eight processor licenses, or a two hundred named user minimum. Walk through it with me. Sixteen cores, times the zero point five core factor, is eight processor licenses. That part most people get. The NUP side is where the traps are. The minimum is twenty five named users per processor. Per processor. So it's eight times twenty five, two hundred named users. Even if only forty people ever touch that system, you're buying two hundred. That's why answer C is wrong, it applies the twenty five just once. Answer A forgot the core factor exists. And D multiplied by two instead of halving, which, hey, at least it's a consistent mistake. Here's what I want you to remember, the minimum, not your headcount, is very often what actually decides the price. And Oracle's sales team knows that arithmetic cold. Now you do too.
Let's go back to that policy versus contract thing, because this gap is where more money changes hands than anywhere else in the Oracle world. Four examples. One, the partitioning policy. The famous one. It says soft partitioning, VMware being the big case, doesn't limit what you license. Two pages, on a website, never signed by you. And it's the foundation of the biggest audit claims Oracle makes. Module five, we take it apart properly. Two, matching service levels. This is the support policy that says you can't drop support on part of a license set while keeping the rest. It's the reason your support bill never shrinks even when you stop using stuff. It's real, it has teeth, but it's negotiable at the right moments, and module four is about finding those moments. Three, the audit scripts. When the audit comes, Oracle sends collection scripts and asks you to run them everywhere. In most contracts? Nothing obligates you to run Oracle's tooling. What you hand over, when, and in what form, that's governed by your audit clause, and it's narrower than the auditors imply. And four, the discipline that ties it together. Oracle's people quote policy fluently, confidently, and it all sounds like contract. Your job is to keep two ledgers in your head. What the signed paper says. What Oracle's policy says. And never, ever let anyone blur the two. That's the muscle. Everything else we do in this course is built on it.
Okay, let's zoom way out and follow one license through its whole life, because this is where you see the game board. Stage one, you buy. The deal closes at some impressive looking discount off list, everyone high fives about the percentage. But the stuff nobody negotiated, price holds, renewal caps, definitions, that stuff quietly prices the next ten years. Stage two, you deploy. And immediately, reality starts drifting away from what you bought. A DBA turns on a feature to fix a problem, turns out that feature is a separately licensed option. VMs migrate. Workloads move. Within a year, what's running doesn't match what was purchased, and nobody's measuring the gap. Stage three, you pay support. Twenty two percent, plus uplift, compounding, on everything you've ever bought. Whether you still use it or not. Stage four, the audit. Oracle shows up, measures all that drift from stage two, and prices it at full list. And here's the pattern I really need you to see. The audit finding is almost never about collecting that scary number. It's leverage. Leverage for the next sale, usually a cloud commitment or a ULA. And stage five, renewal or exit. The one moment of real leverage, for whichever side did their homework. Notice the shape here. Every stage has a default, and every default favors Oracle. Not because anyone's cheating. Because one side runs this play every quarter, and your side sees it maybe once every three years. This course exists to close that gap.
Alright, the five burns. I promised you five findings that drive most of the audit pain. Here they are, and notice how each one connects back to something we've already covered. Burn one, VMware. Under Oracle's soft partitioning position, one database on one VM can pull every host that VM could theoretically reach into scope. Entire vCenter estates. Priced per core. At list. It's the most expensive finding in most audits, and it rests almost entirely on that unsigned policy from earlier. Burn two, enabled options. Partitioning, Advanced Compression, Diagnostics, Tuning. Features that ship inside the database, that a DBA can switch on in an afternoon, and every one carries its own per processor price tag. The audit scripts see everything that was ever enabled. Burn three, Java. Employee metric. Your whole workforce, contractors included, sets the price, not the number of developers actually using Java. And Oracle has the download logs. That's usually how the letter starts. Burn four, ULA exits. An unlimited agreement ends with a certification, where you count and declare what you deployed. Count wrong, or run out of time and do it in a panic, and your best leverage moment turns into another three year unlimited deal you never planned to buy. And burn five, support drift. Companies paying full support on shelfware, for a decade, because matching service levels made cutting it look impossible, and nobody pushed. Every one of these gets a full session later. For today, you just need to hear them coming. Which, let's verify. Last question of the day.
Question three. Your company runs a big, heavily virtualized estate, VMware everywhere, and the Oracle audit lands. Which finding is typically the most expensive one? A, Named User Plus shortfalls on some small databases. B, Diagnostics and Tuning packs that got enabled without licenses. C, soft partitioning scope expansion across the VMware estate. Or D, lapsed support that needs reinstatement fees. Here's a hint before you pause. Ask yourself which of these scales with the size of your infrastructure, instead of with your actual usage. Pause, and pick one.
The answer is C, the VMware scope expansion. And the hint was the whole lesson. Think about how each finding scales. NUP shortfalls, option A, they're real, but they're bounded by how many users you actually have. The enabled packs, option B, real too, annoying, but bounded by the servers where someone clicked the wrong button. Reinstatement, D, that's a support problem, painful but contained. But C? C scales with your infrastructure. One database, on one VM, and the claim expands to every host that VM could reach. Hundreds of hosts. Thousands of cores. At list price. That's how a routine audit turns into an eight figure conversation, and it's exactly why module five gives this one finding an entire session of defense strategy. If you got C, you're already thinking like a licensing person. Two for three or better today, you're in great shape.
So what does the managed version of all this look like? Because it exists, and honestly, it's not complicated. It's just deliberate. Four habits. Habit one, one owner. Somewhere in your org, one named human owns Oracle, with sourcing, IT, and legal in a loop around them. Not a shared mailbox. Not whoever opened the audit letter first. One accountable owner. Habit two, an entitlement library. Every master agreement, every order, every amendment, one place, kept current. When the audit letter shows up, your defense doesn't start with your deployment data. It starts with knowing exactly what you're entitled to. Most companies can't find their own Oracle contracts inside a month. Be the company that finds them in an hour. Habit three, deployment truth. A living record of where Oracle actually runs and which features are on, reconciled against those entitlements on a schedule. Do that, and the audit stops being an ambush. It becomes arithmetic you've already done. And habit four, a calendar. Your renewals, your ULA dates, and, just as important, Oracle's calendar. Their quarter ends. Their fiscal year end, May thirty first. Worked twelve months ahead. Because here's a truth we'll keep coming back to, most leverage with Oracle isn't clever tactics. It's timing. And timing only exists if you planned for it. Do these four things and you're ahead of most of the Fortune 500. I'm not exaggerating.
Let's land this. The whole session, three sentences. One. Oracle is five product families, database, middleware, applications, Java, cloud, each with its own rulebook, all governed by a small stack of signed documents that outrank every policy PDF Oracle has ever published. Two. Two metrics carry most of the money, and it's the counting rules, core factors, minimums, multiplexing, that decide what you owe. Not the list prices. Three. Every stage of the lifecycle, buy, deploy, support, audit, renew, leaks money by default, and the next thirty nine sessions teach you to stop the leak, stage by stage. And if you keep exactly one thing from today, keep the question. Which signed document says so? Next session, we go deep on the metrics. Full processor counting, core factor tables, the twenty five user minimum, multiplexing, with worked examples. And bring a real server spec from your own environment if you can get one, core counts and all. Because we're going to price it, live.
Before session two, homework. About an hour, five items, and I promise every one of them pays off later. One, pull the paper. Find your Oracle Master Agreement, or OLSA, and your three biggest ordering documents. Don't analyze anything. Just locate them, confirm they're complete. And look, if that alone takes you the full hour, that's not a failure, that's a finding. Write it down. Two, sketch the estate. One page. Where does Oracle run in your world? Databases, middleware, apps, Java. Rough is fine, you're drawing your version of the map from today. Three, find the support bill. Last year's Oracle support total, and the date it renews. That number is going to star in module four. Four, on those three orders, note which metric every line item uses. Processor, Named User Plus, employees, whatever it says. Just noticing metrics starts training your eye. And five, write down one question. The single thing about your own Oracle position you can't answer right now. Keep it somewhere safe. Because my actual goal for this course is that by session forty, you answer it yourself, from the signed paper, with total confidence.
Last thing, if you want to go deeper before next time, five reads, all free, all on redress compliance dot com. First, the Oracle vendor management guide. That's the operating model we just talked about, the four habits, expanded into a full playbook. Second, dealing with Oracle sales tactics. Read that one and you'll recognize the quarter end pressure and the policy as contract move the moment they happen to you. Third, conducting internal Oracle license audits. That's your homework, basically, taken to its logical end. Audit yourself before Oracle does it for you. Fourth, how Oracle selects audit targets. The triggers that put you on the list, and, more usefully, the ones you control. And fifth, field tested Oracle negotiation strategies, which is a sneak preview of where this whole course ends up in the capstone. That's session one. You've got the map, you've got homework, and you got at least two of three questions right, I hope. Session two, we start counting. See you there.