标签：#oracle

{ 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