The counting rules that decide what you owe: core factor arithmetic, the Named User Plus definition with multiplexing, the minimums, Standard Edition 2's fence, and one real server priced three ways, from $760,000 to $35,000 at list. Three knowledge checks with real arithmetic, 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.
A taught session with three knowledge checks, and this time every check has real arithmetic: the core factor calculation, the multiplexing count, and the disaster recovery licensing rule. The session ends by delivering session 1's promise: one real server priced live, three ways, and the spread is a twenty to one range decided before any discount conversation.
The full narration of this session, section by section, for reading and reference.
Welcome back. Session two of forty, and today we count. Last time I gave you the map, the five product families, the contract stack, and I told you two metrics carry most of the money. Today we learn to actually run those metrics. Processor and Named User Plus, the full rules. Core factors, the minimums, multiplexing, and the trap cases like standby servers. And I made you a promise last session: bring a real server spec, and we price it live. We're doing exactly that at the end, one server, priced three different ways, and the spread is going to shock you. Same drill as always, three knowledge checks, and today they all have real arithmetic in them, so maybe grab a pen. Thirty minutes. Let's count.
Five things you'll be able to do after today. One, run the core factor math. Hand me any server spec, sockets, cores, chip type, and you convert it to processor licenses in your head. Two, count users honestly. The Named User Plus rules, including the multiplexing rule, which is the one everyone gets wrong the first time. Three, apply the minimums, because on Oracle paper there's a floor under your user count, and that floor often decides the price, not your actual population. Four, place Standard Edition 2. It's the discount option with a fence around it, and knowing exactly where that fence sits saves real money. And five, the big one, price any server both ways and pick the cheaper metric with confidence, using a breakeven rule so clean you can do it on a napkin. That's the session. All of module one, honestly all forty sessions, stand on this counting. Let's start with the four numbers that run the show.
Four numbers, and unlike most vendor math, every one of these comes straight from Oracle's own price list and rules. Number one, zero point five. That's the core factor for Intel and AMD, which is to say, for almost every server you own. Sixteen physical cores, times zero point five, is eight processor licenses. The core factor is the exchange rate between hardware and money. Number two, twenty five. The Named User Plus minimum, per Enterprise Edition processor license. Not per server, per processor license. We'll see in a minute how that floor quietly takes over the pricing. Number three, nine hundred fifty dollars. That's one Named User Plus on Enterprise Edition. And here's the elegant part, it's exactly one fiftieth of the forty seven and a half thousand dollar processor price. Oracle did that on purpose, and it hands us a beautiful breakeven rule: below fifty named users per processor license, counting users is cheaper. Above fifty, count processors. Memorize that ratio and you can sanity check any quote in seconds. And number four, two. The socket cap on Standard Edition 2. Inside that fence, SE2 costs a fraction of EE, and I mean a small fraction, as you'll see when we price the server. Okay. Let's meet the four metrics properly.
The database estate runs on four metrics, two editions times two ways of counting. Metric one, EE Processor. Forty seven five list per license, cores times core factor. This is for systems where you cannot name your users, public websites, big integrated platforms. Metric two, EE Named User Plus. Nine fifty per user, and the definition is wide: every human and every device with access, direct or indirect. Metric three, SE2 per socket. Seventeen and a half thousand per occupied socket, no core factor at all, but only on small servers, two sockets max. Metric four, SE2 Named User Plus, three hundred fifty per user with a gentle floor of ten per server. And then the fifth card, which isn't a metric, it's a multiplier. The options and packs. RAC, Partitioning, Diagnostics, Tuning. Every option is licensed on the same metric and the same count as the database it sits on. Read that again. Same metric, same count. So if you miscount the database by eight processor licenses, and that database runs three options, you just miscounted thirty two licenses, not eight. From the research: roughly two thirds of a typical estate's database spend is options, not the base edition. The counting rules we learn today apply to all of it. Now, the arithmetic.
Core factor arithmetic, chip by chip. The method is three steps. Count the physical cores. Multiply by the factor from Oracle's core factor table. Round up. That's it. The table on screen gives you the factors that matter. Intel and AMD x86, zero point five, so sixteen cores become eight licenses. IBM POWER, a full one point zero, sixteen cores are sixteen licenses, which is why Oracle on POWER hardware is double the license bill of the same cores on Intel, and worth knowing before a hardware refresh, not after. Most modern SPARC chips sit at zero point five as well, and some older SPARC and Itanium entries run from a quarter up to three quarters. Two fine points. First, physical cores, not virtual CPUs, not hyperthreads. The virtualization question, what happens when the database lives on a VM in a big cluster, that's session four, and it's a monster. Today we're counting physical, dedicated hardware, and the good news is the physical rules are genuinely simple. Second, notice where the core factor table lives. It's a published policy document, and your contract's processor definition points at it. Oracle has changed factors before when new chips arrived. Another reason the paper trail matters. Alright. Two servers are waiting on the next slide. Count them.
Knowledge check one. Two production servers. Each has twenty four Intel cores. Both run Database Enterprise Edition. How many processor licenses do you need? A, twenty four. B, forty eight. C, twelve. Or D, thirty two. Pause the video, total the cores first, then apply the factor.
The answer is A, twenty four licenses. Two servers, twenty four cores each, forty eight physical cores total. Times the zero point five Intel factor, twenty four processor licenses. If you said B, forty eight, you forgot the core factor, and you just doubled the bill, which, to be fair, is the mistake Oracle's sales team is least likely to correct for you. C halved twice, an easy slip. And D is what happens when someone counts sockets somewhere in the chain, always ask whether a number is sockets, cores, or licenses, because those three words get swapped constantly in real estates. Now put money on it: twenty four licenses at forty seven five is one point one four million dollars at list. Before a single option. Before support. From one arithmetic step. That's why we drill it.
Now the other direction, counting people. Named User Plus sounds friendly, count your users, pay per user. The definition is wider than anyone expects, in four ways. First, humans with direct access. Everyone authorized to touch the database, whether or not they ever log in. Authorization counts, not activity. That inactive account from someone who left last year? Counts until it's removed. Second, and this is the big one, humans through other systems. The multiplexing rule. If people use an application, and that application reads from or writes to your Oracle database, those people count as if they touched the database directly. Pooling everything through one service account changes nothing. The rule exists precisely to close that loophole. Third, devices. Non human things that access the database, sensors, scanners, integration jobs, each one is a named user. A warehouse with two hundred barcode scanners has two hundred named users before a single human logs in. And fourth, the floor. On EE, twenty five named users per processor license, minimum, whether those people exist or not. So the counting order is: processors first, floor second, actual population third, and you pay the bigger of the two. Let's test the multiplexing rule, because this is the exam question real audits are made of.
Knowledge check two. Three hundred employees use a CRM application. The CRM stores everything in one Oracle Enterprise Edition database, and it connects through a single service account. How many named users does that database need? A, one, because only the service account touches the database. B, three hundred, every CRM user counts through multiplexing. C, twenty five, the minimum covers it. Or D, zero, the CRM vendor's license covers the database. Pause here, and think about what the front end changes, and what it doesn't.
The answer is B, three hundred. The service account is exactly the case the multiplexing rule was written for. Middleware, connection pooling, a single technical login, none of it shrinks the count. The humans at the front end are the named users. And notice, answer A is not a silly answer, it's the intuitive answer, which is why this finding shows up in audit after audit. The scripts see the application connections, the auditors ask what sits in front, and the count jumps from one to three hundred at nine hundred fifty dollars each. C misreads the minimum. Twenty five per processor is a floor, not a ceiling, it never caps your obligation. And D, D is only true when the application vendor sold you an embedded or application specific license with the database included in the price. Those grants exist, we cover them in session seven, but they're specific words on specific paper. Never the default assumption. The lesson: count the humans behind every front end, honestly, because Oracle certainly will.
Let's talk about the discount with a fence around it, Standard Edition 2. The price first, because it's startling. Seventeen and a half thousand per socket, no core factor, cores don't matter at all. A fully loaded two socket server, thirty five thousand dollars at list. The same iron on Enterprise Edition can be three quarters of a million. And SE2 Named User Plus is three fifty a user with a floor of just ten per server. So where's the catch? The fence. Rule one, SE2 only runs on servers with a maximum capacity of two sockets. Not two occupied sockets, two socket capacity, the empty slot counts against you. Rule two, each SE2 database uses at most sixteen CPU threads at any moment. For a huge share of departmental workloads, that's plenty. Rule three, the floor of ten named users per server, which is gentle. And rule four, the real catch, what you give up. No Enterprise Edition options, no Partitioning, no Diagnostics pack, and no RAC on current releases. And if the workload outgrows the fence, there's no upgrade path discount, you repurchase at EE prices. So SE2 is a genuine gift for stable, modest workloads, and a trap for workloads that grow. The discipline is planning the growth path before you commit, not after the sixteen threads run out. Right. You now know all four metrics. Let's put the method together.
Here's the method, five steps, run it for every database environment you own. It takes minutes per system and it routinely finds six figure differences. Step one, count cores. Physical cores times core factor, gives you the processor license count. Step two, count people. Every human, every device, through every front end, honestly, the way we just learned. Step three, apply the floors. On EE, twenty five per processor license. On SE2, ten per server. Your billable user count is the bigger of the floor and the real population. Step four, price both routes. Processor count times forty seven five. User count times nine fifty. And don't forget both carry twenty two percent support per year on top, forever, so the license delta compounds. And step five, pick per system, using the breakeven: fifty named users per processor license. Below fifty, the user route wins. Above, processors. And because Oracle set the prices at exactly one to fifty, that rule never drifts. One more thing, pick per system means per system. A well run estate mixes metrics deliberately, NUP on the small known populations, processor on the public facing systems, SE2 inside the fence. The estates that pay too much are the ones that defaulted everything to one metric years ago and never re-ran the math. Now, the ways this goes wrong in the wild.
Five counting traps, and every one of them is a real audit finding I've seen priced. Trap one, the cluster expansion. Everything we did today assumed dedicated physical servers. Put that database on a VM in a big virtualized cluster, and Oracle's soft partitioning position says count every host the database could reach. The count explodes from one server to the whole farm. That's session four, entirely. I'm flagging it today so nobody leaves this session and confidently counts a VMware estate with the physical rules. Trap two, the multiplexing undercount. We just did it. Counting the service account instead of the humans. The audit scripts see the connection patterns, and the auditors always ask what's in front. Trap three, the forgotten floor. Eighty real users on an eight processor license system. Sounds like eighty NUP, it's actually a two hundred NUP minimum, and the hundred twenty license shortfall surfaces in the audit, priced at list. Trap four, the standby server. If Oracle software is installed and running on your DR box, it generally needs full licenses, same metric, same count as production. There is one narrow exception, and it's the subject of the next question. And trap five, internet facing NUP. A public website's users are uncountable by definition, so Named User Plus on a public system is a compliance finding waiting to be written. Those systems belong on processor. Alright, the DR question. This one settles arguments in real companies every week.
Knowledge check three. Your disaster recovery site has a standby server. Oracle is installed, data is replicated to it continuously, it's ready to take over the moment production fails. Does it need licenses? A, no, only production environments need licenses. B, yes, fully licensed, unless it's a true passive failover used at most ten separate days a year. C, only if a disaster actually happens. Or D, no, DR servers are automatically covered at half price. Pause here. The word that matters is replicated.
The answer is B. That standby server needs full licenses, same metric, same count as production. Here's the reasoning. Continuous replication means Oracle software is installed and actively running on that box, it's applying changes all day long. That's use, and use is licensed. The narrow exception people half remember is the ten day failover rule: a genuinely passive node in a failover cluster, one that only mounts and opens the database when production actually dies, can run unlicensed for up to ten separate days per year. Ten days, counted separately, per cluster arrangement. A continuously synchronized standby is nowhere near that exception. And the wrong answers are popular beliefs, which is the problem. A, only production counts, is folklore. C, licensed only when disaster strikes, is folklore. D, the automatic DR discount, pure folklore, no such rule exists anywhere in Oracle's paper. This is why DR appears in audit findings so reliably, entire estates built on assumptions that were never in the contract. If your DR topology hasn't been checked against the licensing rules, that's not a detail, that's potentially seven figures. Okay. Time to keep my promise from session one. Let's price a real server, live.
One server, priced every way the rules allow. The spec: two sockets, thirty two Intel cores, four hundred users behind its applications. Route one, EE Processor. Thirty two cores times zero point five, sixteen licenses. Sixteen times forty seven five, seven hundred sixty thousand dollars at list, and about a hundred sixty seven thousand a year in support, forever. Route two, EE Named User Plus. Four hundred real users. Check the floor: sixteen licenses times twenty five is four hundred exactly, so the floor and the population agree. Four hundred times nine fifty, three hundred eighty thousand, half the processor route, and about eighty three and a half thousand a year in support. And the crossover confirms it: sixteen licenses times fifty is eight hundred users. We're at four hundred, well below, so NUP wins, exactly as the rule predicts. Route three, and here's the stunner. If that workload fits SE2's fence, two sockets, sixteen threads, no EE options needed, it's two sockets times seventeen five. Thirty five thousand dollars. Under eight thousand a year in support. Look at the spread. Same server, same workload: seven sixty, three eighty, or thirty five thousand. A twenty to one range, decided before anyone negotiates a discount percentage. This is what I mean when I say the metric and edition decision is the negotiation before the negotiation. Discounts move a deal twenty, thirty percent. Counting decisions move it twenty to one.
Let's land it. Session two in three sentences. One, processor licensing is physical cores times the core factor, and Named User Plus is every human and device through every front end, with a floor of twenty five per processor license. Two, the breakeven is fifty named users per processor license, Oracle priced it that way on purpose, so count both ways and price both ways for every system, every time. Three, the expensive mistakes aren't arithmetic, they're scope: multiplexing, standby servers, and the cluster question we've now flagged twice. And keep the big number from today in your pocket: same server, seven hundred sixty thousand or thirty five thousand, depending on decisions that happen before any discount conversation. Next session, we go inside the editions. Enterprise versus Standard Edition 2 in full, and the options trap, the separately licensed features that install by default, run without a license key, and make up two thirds of most database spend. If today was about counting correctly, session three is about knowing exactly what you're counting. See you there.
Homework, about an hour, and this week it's a drill, the same drill we just did, on your own hardware. One, pick one real server. Production, something that matters. Get the socket count, the physical core count, and the chip type from your infrastructure team. Two, run the core factor math. Cores times factor, write down the processor license count. Three, count its users honestly. List every application that touches that database, and the humans behind each one. Front ends included, multiplexing rule applied. Four, price it both ways. Processor route, NUP route with the floor, which one wins and by how much? If the gap surprises you, you've just found this week's value. And five, check your paper. Open your own ordering documents and find the processor definition and the Named User Plus definition. Most are standard, but custom definitions exist, older contracts sometimes carry better terms than today's standard, and you need to know which you have before you rely on anything I taught today. That's the hour. Next week, bring what you found.
Five reads to go deeper, all free on redress compliance dot com. First, how to check your Oracle license position, three practical ways to establish what you actually own, which is the starting point every count depends on. Second, the CIO playbook on Oracle's evolving pricing metrics, how the metrics and bundles shift over time and what that does to old entitlements. Third, hard partitioning done properly, the approved technologies that genuinely cap processor counts, read it and you're ahead of half of session four already. Fourth, interpreting LMS script output, what Oracle's own measurement tooling sees, including exactly how the multiplexing evidence shows up. And fifth, conducting internal Oracle license audits, which turns this week's one server drill into a standing process across the estate. That's session two. You can count cores, you can count people, and you know the breakeven. Session three, the editions and the options trap. See you there.