Standard Edition

Standard Edition 2 Limits: 2 Sockets, 16 Threads, and No Packs

3 November 2026

Oracle Standard Edition 2 is the same database engine as Enterprise Edition at a fraction of the price, and the price comes with limits in three places: the hardware it may run on, the features the licensing manual marks as not available, and the management packs, which cannot be licensed for it at all. The limits are not hidden, but they are spread over a data sheet, a 120-page licensing manual and a feature table with nine columns. This page puts them in one list, each from Oracle's own document, with what it means on a Tuesday morning, and ends with how Scops monitors an SE2 database in full without touching anything the manual reserves for the packs.

The hardware limits

Oracle's licensing data sheet states both rules in one paragraph. Standard Edition 2 "may only be licensed on servers that have a maximum capacity of 2 sockets", and "each Oracle Database Standard Edition 2 database may use a maximum of 16 CPU threads at any time". The socket rule is about the server's capacity, not what is populated: a four-socket chassis with two sockets filled is not an SE2 server. The thread rule is enforced by the database itself, so an SE2 instance on a 32-thread host runs on 16 of them whatever CPU_COUNT the host reports, and a workload that could use the other sixteen does not. The license is counted per occupied socket rather than per core, which is what makes SE2 cheap on a two-socket server with many cores, and the Named User Plus minimum is 10 named users per server rather than 25 per processor. Since 19c, Oracle RAC is not available on Standard Edition 2 at all; the manual's table marks RAC as N for SE2 and marks Standard Edition High Availability, a cold failover of one instance between the nodes of a cluster, as Y.

The feature limits, from the licensing manual

The Database Licensing Information User Manual has the feature tables, with a column for each offering. The SE2 and on-premises Enterprise Edition columns, row by row, with the manual's own notes:

The manual's cells are Y and N; "Extra cost option" is its note on Enterprise Edition. Every N in the SE2 column is a limit that the database enforces for you: a CREATE TABLE ... PARTITION BY on SE2 fails with ORA-00439, so compliance is not the risk. The risk is the plan that was written for the feature. One line of the same table is good news, and it is the same on both editions: "SQL Plan Management does not require a license for Oracle Diagnostics Pack or Oracle Tuning Pack", so a plan that flipped can be pinned with a SQL plan baseline on SE2 too.

What each limit means on a Tuesday morning

Sixteen threads. The month-end report runs on one of them, and the other fifteen serve the users; when a single statement takes a thread for an hour, the fix is the statement, because there is no parallel degree to give it. The CPU page applies with a cap of sixteen. No partitioning. A table that grows by a year of rows every year is pruned with a DELETE, which generates undo and redo for every row and holds the table for the duration; the archiving approach, old rows moved in small committed chunks while the application runs, is how SE2 shops keep tables at working size. No compression. The space forecast matters more, because nothing slows the growth; the growth page has the queries. No managed standby. The scripted log shipping needs its own check that the last archived log reached the other side and was applied. No online rebuild. Index rebuilds and table moves go in the maintenance window, and the unusable index page says what happens when one is forgotten. No packs. The slow hour of yesterday has no AWR report and no ASH to replay; session history has to come from somewhere else, which the SE2 monitoring page covers in full.

Check where an SE2 database stands

SELECT banner_full FROM v$version;

SELECT name, value
FROM   v$parameter
WHERE  name IN ('cpu_count', 'control_management_pack_access');

SELECT stat_name, value
FROM   v$osstat
WHERE  stat_name IN ('NUM_CPUS', 'NUM_CPU_CORES', 'NUM_CPU_SOCKETS');

SELECT COUNT(*) AS user_pdbs FROM v$pdbs WHERE con_id > 2;

The banner names the edition. NUM_CPU_SOCKETS against the two-socket rule and NUM_CPUS against sixteen say what the host offers and what the database may use. CONTROL_MANAGEMENT_PACK_ACCESS should read NONE, which is its default on every edition but Enterprise. And on SE2, DBA_FEATURE_USAGE_STATISTICS should show no detected use of AWR, ADDM or Active Session History, because there is no license that could cover one.

How Scops monitors Standard Edition 2

Scops monitors SE2 databases in full, with nothing that the manual puts in a pack: every session is sampled every 5 seconds from V$SESSION, the SQL figures every 10 minutes from V$SQL, into a repository of its own, so the slow hour of yesterday is on the Activity chart with its statements and waits, on SE2 exactly as on Enterprise Edition. Radar Engine's 75+ detectors watch what SE2 leaves to the DBA: the growth of every tablespace with the date it fills, the backups, the jobs, the accounts, the one statement taking the sixteen threads, and the scripted standby's archived logs. The License page counts SE2 by sockets, as Oracle does, and flags any pack use on a Standard Edition database as Needs Attention, because there it can never be licensed. Scops AI reads all of it with 40+ agentic tools. The read-only account needs CREATE SESSION and SELECT_CATALOG_ROLE, and the price is the same on every edition: free for two databases, then $499 per database a year.

Questions

What are the limits of Oracle Standard Edition 2?
Servers with a maximum capacity of 2 sockets, 16 CPU threads per database at any time, no Oracle RAC since 19c, at most 3 user-created PDBs, and the features the licensing manual marks N for SE2: parallel execution, partitioning, compression, Data Guard redo apply, online rebuilds, flashback, and the Diagnostics and Tuning Packs.

Can Standard Edition 2 use more than 16 CPU threads?
No. The data sheet limits each SE2 database to 16 CPU threads at any time, and the database enforces it, so extra cores on the host are not used by the instance. A statement cannot run in parallel on SE2 either.

Does Standard Edition 2 support RAC?
Not since 19c. The licensing manual's table marks Oracle RAC as N for SE2 and Standard Edition High Availability as Y: one instance that fails over to another node of the cluster, with a short outage, rather than two instances running at once.

Can I use AWR, ASH or the Diagnostics Pack on Standard Edition 2?
No. The manual marks both packs as N for SE2, so there is no license to buy, and the pack views such as V$ACTIVE_SESSION_HISTORY and the DBA_HIST views must not be used. Session history on SE2 comes from sampling V$SESSION, which is what Scops does on any edition.

How many PDBs can Standard Edition 2 have?
Three user-created pluggable databases in a container database, per the manual's Multitenant row; Enterprise Edition with the Multitenant option goes to 252.

Related

• Oracle Standard Edition 2 monitoring without the packs
• What the Oracle Diagnostics Pack costs
• Session history without the Diagnostics Pack
• Archive old rows without partitioning
• Scops vs Enterprise Manager, DPA, Foglight and Datadog: one table
• Diagnostics Pack usage: how to check it
• resmgr:cpu quantum
• Is AWR free? Is ASH licensed?

Sources

• Oracle: Database Licensing (data sheet: sockets, CPU threads and Named User Plus minimums for Standard Edition 2), Database Licensing Information User Manual (feature tables)
• Oracle: V$OSSTAT, CONTROL_MANAGEMENT_PACK_ACCESS
• Scops docs: License, Detector reference, Requirements