标签：#Oracle

Many databases use B+tree indexes, but they all differ. It's a sorted structure. The leaf pages are logically sorted so that a specific key value belongs to one page. A lookup by value reaches a single leaf page and either directly finds an entry for that value or immediately knows there's no entry with that key. When a page becomes full, it is split into two pages, each covering its own dedicated range. To find the right page, an internal page holds the range of values for the pages below. This internal page can become full, and a new level is added above it. Finally, at the highest level, there's a single internal page that is the root. A lookup always starts at the root and goes down to the leaves, following the branches of internal pages. In a traditional B+tree lookup, the cost is proportional to the height of the tree because the search starts at the root and descends to a leaf: 1 page to read when all fits in one leaf that is also the root (0 levels of internal pages, total height is 1). With small keys, this level can typically index hundreds of rows. 2 pages to read when there's one root that can list all leaf pages (1 level of internal page, total height is 2). With small keys, this level can typically index tens or hundreds of thousands of rows. 3 pages to read when there's one level of branches under the root (so 2 levels of internal pages, total height is 3). With small keys, this level can typically index millions of rows. This means that finding one key within ten million rows may require traversing 3 index pages, where most of them are probably in cache given the small number of branches compared to the leaves. For a given index size, whatever the value you are looking for, it's always the same number of pages to read because the index is balanced (the commonly accepted meaning of the B in B+tree). This property is maintained because any page can split, but only splitting the root adds another level. I've described how the height of an index can incr

This week's Java roundup for July 13th, 2026, features news highlighting: a reintroduction of Value Objects (Preview); the GA release of WildFly 41; the July 2026 edition of Open Liberty 26.0.0.7; point releases of TornadoVM, Apache TomEE, Java Operator SDK and LangChain4j; a maintenance release of Micronaut; a new extension, Quarkus Shim; and a new Oracle AI Agent Studio for Fusion Applications. By Michael Redlich

{ Abhilash Kumar Bhattaram : Follow on LinkedIn } The Post-Migration Mirage For many Chief Technology Officers (CTOs), the successful cutover of a core database to the cloud feels like the ultimate victory lap. The data has landed, the connection strings are updated, and initial performance metrics look stellar. But there is a dangerous mirage that follows a cloud database migration: Hidden Downtime. Unlike an abrupt database crash, hidden downtime is a slow-burn operational decay. It happens when day-to-day transactions process smoothly in production, but the underlying database ecosystem—specifically the disaster recovery (DR) standby instances, secondary cross-region sites, and replication pipelines—quietly falls out of sync. When a true disruption occurs and you try to failover or scale, the database tier collapses. To ensure true, 24/7 predictability, forward-thinking CTOs look beyond the immediate "Go-Live" date. The ultimate challenge is navigating the dense maze of cloud onboarding options to find the exact database migration method that fits your specific application topology. Ground Zero: The Database Configuration Drift The root cause of post-migration database downtime begins long before cutover day, it starts with how the database is moved and how its configuration is maintained. Going to the cloud offers various technical pathways, but the overarching challenge is finding what fits your unique architecture. The initial migration must establish perfect baseline parity, but standard database operations and hasty migration choices quickly introduce fatal configuration drift. To manage this drift effectively, organizations must introduce rigorous baseline metrics before, during, and after the migration process: - Benchmarking Versions: Ensuring that source and target database patch levels, Timezone (TZ) files, and Release Updates (RUs) match exactly. Mismatched database versions between primary cloud instances and standby homes create silent dictionary inc

Oracle halved the Always Free Ampere A1 compute allowance from 4 OCPUs and 24 GB RAM to 2 OCPUs and 12 GB RAM with no public announcement. Support agents gave conflicting answers on whether PAYG accounts are affected. Documentation states the new limits apply to "all tenancies" while support emails say only free-tier accounts. By Steef-Jan Wiggers

Key Takeaways Oracle Backend for Microservices and AI 2.1.0 is a platform modernization release. It updates several shared backend concerns at once, including external access, observability, configuration, messaging, database deployment choices, workflow, samples, enterprise installation planning, and upgrades. Gateway API and Envoy Gateway are now the default external access direction. NGINX Ingress Controller is deprecated, disabled by default, and still available only when explicitly enabled. The release gives platform teams clearer building blocks. OpenTelemetry Operator, Java auto-instrumentation, Spring Config Server, Kafka through Strimzi-managed resources, and clearer database deployment choices supported by Oracle AI Database Operator for Kubernetes make important platform choices easier to see and discuss. Enterprise adoption still needs architecture review. Before adopting or upgrading, teams should review private registry needs, air-gapped installation requirements, multi-tenant installation goals, workflow implications, database deployment choices, and upgrade readiness. OBaaS 2.1.0 is a platform modernization release Oracle Backend for Microservices and AI , or OBaaS , is a backend-as-a-service style platform for teams building microservices and AI-enabled applications with Oracle AI Database as a core data foundation. It brings common backend platform concerns together: service access, telemetry, configuration, messaging, workflow, and database connectivity. That matters because most teams do not want every application squad to rebuild those pieces on its own. They want a platform shape that gives developers useful defaults while still giving architects, DBAs, security teams, and operators the control points they need. This article focuses on the Oracle Backend for Microservices and AI 2.1.0 update. The best way to read OBaaS 2.1.0 is not as a single-feature release. It is a platform modernization release. The update moves the default external access

The Database resource in Oracle Cloud Infrastructure Database service provides an optional auto_backup_window option in its API during creation ( Terraform resource: oci_database_database ). The database resource can be used in an OCI Base DB system or Exadata Cloud VM Cluster pluggable database (PDB) for example. The time window enum value selected for initiating automatic backup for the database system is available in twelve two-hour UTC time windows as the following: Slot Description SLOT_ONE 12:00AM - 2:00AM UTC SLOT_TWO 2:00AM - 4:00AM UTC SLOT_THREE 4:00AM - 6:00AM UTC SLOT_FOUR 6:00AM - 8:00AM UTC SLOT_FIVE 8:00AM - 10:00AM UTC SLOT_SIX 10:00AM - 12:00PM UTC SLOT_SEVEN 12:00PM - 2:00PM UTC SLOT_EIGHT 2:00PM - 4:00PM UTC SLOT_NINE 4:00PM - 6:00PM UTC SLOT_TEN 6:00PM - 8:00PM UTC SLOT_ELEVEN 8:00PM - 10:00PM UTC SLOT_TWELVE 10:00PM - 12:00AM UTC Timezone used for the slots is always UTC regardless of the timezone used in the database. For example, if the user selects SLOT_TWO from the enum list, the automatic backup job will start in between 2:00 AM (inclusive) to 4:00 AM (exclusive) If no option is selected, a start time between 12:00 AM to 7:00 AM in the region of the database is automatically chosen. Reference Terraform resource: oci_database_database OCI API Reference: Database DbBackupConfig Safe harbor statement The information provided on this channel/article/story is solely intended for informational purposes and cannot be used as a part of any contractual agreement. The content does not guarantee the delivery of any material, code, or functionality, and should not be the sole basis for making purchasing decisions. The postings on this site are my own and do not necessarily reflect the views or work of Oracle or Mythics, LLC. This work is licensed under a Creative Commons Attribution 4.0 International License (CC-BY 4.0) .

Oracle is spending billions on data center infrastructure to support AI.

pgrac is an open attempt to rebuild Oracle RAC's core machinery (shared-everything storage, multiple active nodes all writing one database, a cluster-wide change number) on top of PostgreSQL 16. Build log #1 laid out the four problems that fight back. This one is about the problem that turns a node failure into silent data corruption, and the first, deliberately modest, layer pgrac ships against it. The failure mode In a shared-nothing cluster an evicted node is mostly harmless: it owns its own disks, so the cluster routes around it. In a shared-everything cluster the same event is dangerous, because every node writes the same storage. Picture the classic split: node 2 misses heartbeats, the cluster declares it dead and remasters its work elsewhere, but node 2 is not actually dead. It is frozen on a long GC pause, or its interconnect NIC flaked, and it is about to wake up and finish the write it started. Now two nodes believe they own the same blocks, and shared storage will accept both writes. That is not a crash. It is corruption you find three days later. Oracle RAC's answer is I/O fencing: before remastering a dead node's resources, you make certain it can no longer touch the storage, with STONITH, SCSI-3 persistent reservations, or a hardware watchdog. The node is fenced at a layer below its own software, because the whole point is that you cannot trust the dead node's software to behave. That hardware layer is real work, and it is not what pgrac built first. What it built first is the layer above it: an in-process cooperative write-fence, now default-ON. The rest of this is precise about what that does and does not buy you, because "we have fencing" is the kind of claim that is worth less than nothing if it is overstated. A fence needs an authority everyone can agree on You cannot fence on local opinion, because the whole problem is that the dead node disagrees about being dead. Authority has to live on durable, shared, quorum-backed storage. pgrac writes a sm

Vulnerability in the Oracle-owned PeopleSoft software is about as critical as they come.

The tech giant warned of a security flaw that a cybercrime gang said it's exploiting as part of a mass-hacking campaign. Google said it notified more than 100 organizations that had potentially vulnerable servers.

ORA-00031: Session Marked for Kill — What It Means and How to Fix It ORA-00031 occurs when a DBA issues ALTER SYSTEM KILL SESSION but Oracle cannot terminate the target session immediately. Instead, Oracle marks the session as "KILLED" and waits for it to reach a safe termination point — typically after completing a rollback or releasing OS-level resources. This is less of a hard error and more of a transitional state that every Oracle DBA will eventually encounter. Top 3 Causes 1. Large Transaction Rollback in Progress When you kill a session mid-transaction, Oracle must roll back all uncommitted changes to preserve data integrity. The larger the transaction, the longer the session stays in KILLED status. -- Check rollback progress for KILLED sessions SELECT s . sid , s . serial # , s . username , t . used_ublk AS undo_blocks , t . used_urec AS undo_records FROM v $ session s JOIN v $ transaction t ON s . taddr = t . addr WHERE s . status = 'KILLED' ; 2. Unresponsive or Disconnected Client If the client network connection is broken or the client process has hung, Oracle cannot deliver the kill signal. The session lingers in KILLED state until the OS-level connection finally times out. -- Find the OS process ID (SPID) for stuck KILLED sessions SELECT s . sid , s . serial # , s . username , s . status , p . spid AS os_pid , s . machine , s . program FROM v $ session s JOIN v $ process p ON s . paddr = p . addr WHERE s . status = 'KILLED' ; 3. OS-Level I/O or Resource Wait Sessions blocked at the OS level (disk I/O stall, memory pressure, storage issues) cannot respond to Oracle's internal kill signal. In these cases, only an OS-level process termination will resolve the problem. -- Identify what the session was waiting on before being killed SELECT sid , serial # , status , event , wait_class , seconds_in_wait FROM v $ session WHERE status = 'KILLED' ; Quick Fix Solutions Option 1 — Use the IMMEDIATE keyword (recommended first step) -- Standard kill (asynchronous) AL