Oracle Database In-Memory (DBIM) provides orders of magnitude speedup for analytic queries with its highly compressed, transactionally consistent, memory-optimized Column Store. Customers can use Oracle DBIM for making real-time decisions by analyzing vast amounts of data at blazingly fast speeds. Active Data Guard (ADG) is Oracle's comprehensive solution for high-availability and disaster recovery for the Oracle Database. Oracle ADG eliminates the high cost of idle redundancy by allowing reporting applications, ad-hoc queries and data extracts to be offloaded to the synchronized, physical Standby database replicated using Oracle ADG. In Oracle 12.2, we extended the DBIM advantage to Oracle ADG architecture. DBIM-on-ADG significantly boosts the performance of analytic, read-only workloads running on the physical Standby database, while the Primary database continues to process high-speed OLTP workloads. Customers can partition their data across the In-Memory Column Stores on the Primary and Standby databases based on access patterns, and reap the benefits of fault-tolerance as well as workload isolation without compromising on critical performance SLAs. In this paper, we explore and address the key challenges involved in building the DBIM-on-ADG infrastructure, including synchronized maintenance of the In-Memory Column Store on the Standby database, with high-speed OLTP activity continuously modifying data on the Primary database.

Oracle's Real Application Cluster (RAC) allows multiple database instances to run on different server nodes in a cluster against a shared set of data files. A critical aspect of an Oracle RAC system is that of instance recovery. When a node suffers from a hardware failure, or a database instance suffers from a software failure, instance recovery is performed by a surviving instance to ensure that the database remains in a consistent state. High-availability comes from the surviving database instances, each running on a surviving node, that are still able to provide database services. During instance recovery, the set of database resources that are in need of recovery must be identified, locked and then repaired. Until such time as the identification and locking of these resources has been done, Oracle needs to block any requests by database clients to all database resources. The whole database appears to be frozen during this time, a period that is called application brown-out. In the interests of availability it is therefore important that instance recovery endeavors to keep this period of identification and locking as short as possible. In doing so, not only is the brown-out period reduced, but also the overall time to make available those resources that need repair, is reduced. This paper describes the use of a Buddy Instance, a mechanism that significantly reduces the brown-out time and therefore also, the duration of instance recovery. Each database instance has a buddy database instance whose purpose is to construct in-memory metadata that describes the resources needing recovery, on a continuous basis at run-time. In the event of node or instance failure, the buddy instance for the failed instance uses the in-memory metadata in performing instance recovery. The buddy instance mechanism was introduced in the 12.2.0.1 release of Oracle Database to minimize and potentially eliminate the period of identification of resources needing recovery. This mechanism was enhanced in the 12.2.0.2 release of Oracle Database by the construction of a Bloom filter that temporarily serves the purpose of locking the identified resources, thereby enabling the database to be made available sooner than was previously the case.

In this paper we consider the problem of on-line scheduling of real-time tasks which receive a that depends on the amount of service received. In our model, tasks have associated deadlines at which they must depart the system. The task computations are such that the longer they are able to execute before their deadline, the greater the value of their computations, i.e., the tasks have the property that they receive increasing reward with increasing service (IRIS). We focus on the problem of scheduling IRIS tasks in a system in which tasks arrive randomly over time, with the goal of maximizing the average reward accrued per task and per unit time. We describe and evaluate a two-level policy for this system. A top-level algorithm executes each time a task arrives and determines the amount of service to allocate to each task in the absence of future arrivals. A lower-level algorithm, an earliest deadline first (EDF) policy in our case, is responsible for the actual selection of tasks to execute. This two-level policy is evaluated through a combination of analysis and simulation, We observe that it provides nearly optimal performance when the variance in the interarrival times and/or laxities is low and that the performance is more sensitive to changes in the arrival process than the deadline distribution.