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.

This paper analyzes web server performance under simulated WAN conditions. The workload simulates many critical network characteristics, such as network delay, bandwidth limit for client connections, and small MTU sizes to dial-up clients. A novel aspect of this study is the examination of the internal behavior of the web server at the network protocol stack and the device driver. We discovered that WAN network characteristics may significantly change the behavior of the web server compared to LAN-based simulations and may make many of optimizations of server design irrelevant in this environment. Particularly, we found that the small MTU size of the dial-up or wireless user connections can increase the processing overhead several times.