Abstract: A computing device is configured to allocate memory for exclusive use of an execution entity from both a shared memory area and a private memory area of the device. Specifically, the shared memory area is configured with a united memory pool (UMP) component. The UMP component is configured to provide portions of huge page-based memory to execution entities for exclusive use of the execution entities. Memory granules that are allocated to the UMP component are divided into smaller memory chunks (which are smaller than a huge page), each of which can be allocated for exclusive use of an execution entity. These memory chunks are mapped to virtual address spaces of the assigned execution entities. Because memory granules can be allocated to, and deallocated from, the UMP component at run-time, the amount of memory that is available for private data generated by execution entities is able to be dynamically adjusted.

Abstract: Techniques are described herein for effectively managing usage of a shared object cache in a container database management system (DBMS). The shared object cache maintains shared objects belonging to a set of pluggable databases (PDBs) hosted by the container DBMS. In an embodiment, a shared object metadata extension structure (SOMEX) is maintained for each PDB. The SOMEX stores metadata for each shared object of the PDB that resides in the shared object cache. In an embodiment, a share of the shared object cache is maintained for shared objects from each PDB in the set of PDBs based on entries in the SOMEX for the PDB.

Abstract: Techniques are provided for using an intermediate cache to provide some of the items involved in a scan operation, while other items involved in the scan operation are provided from primary storage. Techniques are also provided for determining whether to service an I/O request for an item with a copy of the item that resides in the intermediate cache based on factors such as a) an identity of the user for whom the I/O request was submitted, b) an identity of a service that submitted the I/O request, c) an indication of a consumer group to which the I/O request maps, d) whether the I/O request is associated with an offloaded filter provided by the database server to the storage system, or e) whether the intermediate cache is overloaded. Techniques are also provided for determining whether to store items in an intermediate cache in response to the items being retrieved, based on logical characteristics associated with the requests that retrieve the items.

Abstract: Techniques are described herein for effectively managing usage of a shared object cache in a container database management system (DBMS). The shared object cache maintains shared objects belonging to a set of pluggable databases (PDBs) hosted by the container DBMS. In an embodiment, a shared object metadata extension structure (SOMEX) is maintained for each PDB. The SOMEX stores metadata for each shared object of the PDB that resides in the shared object cache. In an embodiment, a share of the shared object cache is maintained for shared objects from each PDB in the set of PDBs based on entries in the SOMEX for the PDB.

Abstract: Automated management of shared I/O resources involves use of a policy engine for implementing I/O scheduling group I/O policies. The I/O policies are used for determining whether corresponding I/O requests should be issued to a shared storage system immediately or should be delayed via corresponding policy-based queues. In the context of database systems, a database administrator can specify policies regarding how I/O resources should be used and the database system itself enforces the policies, rather than requiring the database administrator enforce the I/O usage of the database and of the individual users.

Abstract: Techniques are provided for using an intermediate cache to provide some of the items involved in a scan operation, while other items involved in the scan operation are provided from primary storage. Techniques are also provided for determining whether to service an I/O request for an item with a copy of the item that resides in the intermediate cache based on factors such as a) an identity of the user for whom the I/O request was submitted, b) an identity of a service that submitted the I/O request, c) an indication of a consumer group to which the I/O request maps, or d) whether the intermediate cache is overloaded. Techniques are also provided for determining whether to store items in an intermediate cache in response to the items being retrieved, based on logical characteristics associated with the requests that retrieve the items.

Abstract: Automated management of shared I/O resources involves use of a policy engine for implementing I/O scheduling group I/O policies. The I/O policies are used for determining whether corresponding I/O requests should be issued to a shared storage system immediately or should be delayed via corresponding policy-based queues. In the context of database systems, a database administrator can specify policies regarding how I/O resources should be used and the database system itself enforces the policies, rather than requiring the database administrator enforce the I/O usage of the database and of the individual users.

Abstract: Automated management of shared I/O resources involves use of a policy engine for implementing I/O scheduling group I/O policies. The I/O policies are used for determining whether corresponding I/O requests should be issued to a shared storage system immediately or should be delayed via corresponding policy-based queues. In the context of database systems, a database administrator can specify policies regarding how I/O resources should be used and the database system itself enforces the policies, rather than requiring the database administrator enforce the I/O usage of the database and of the individual users.

Abstract: Techniques are provided for using an intermediate cache to provide some of the items involved in a scan operation, while other items involved in the scan operation are provided from primary storage. Techniques are also provided for determining whether to service an I/O request for an item with a copy of the item that resides in the intermediate cache based on factors such as a) an identity of the user for whom the I/O request was submitted, b) an identity of a service that submitted the I/O request, c) an indication of a consumer group to which the I/O request maps, d) whether the I/O request is associated with an offloaded filter provided by the database server to the storage system, or e) whether the intermediate cache is overloaded. Techniques are also provided for determining whether to store items in an intermediate cache in response to the items being retrieved, based on logical characteristics associated with the requests that retrieve the items.

Abstract: Automated management of shared I/O resources involves use of a policy engine for implementing I/O scheduling group I/O policies. The I/O policies are used for determining whether corresponding I/O requests should be issued to a shared storage system immediately or should be delayed via corresponding policy-based queues. In the context of database systems, a database administrator can specify policies regarding how I/O resources should be used and the database system itself enforces the policies, rather than requiring the database administrator enforce the I/O usage of the database and of the individual users.

Abstract: A routing process for a single-instruction-multiple-data (SIMD) multi-level hierarchical network of nodes, which are arranged in clusters and interconnected by dual, unidirectional channels, are used to send data packets including routing address information during a succession of routing cycles from transmitting ones to receiving ones of a large number of parallel processors (e.g., 4096 processors arranged in a hierarchy of 8 cabinets, each of which contains a cluster of 8 circuit boards, with each circuit board containing a cluster of 64 processors). Each of the nodes includes a storage buffer having a capacity equal to a given number which is one more than the total number of channels terminating at that node. This routing process guarantees prevention of deadlock between levels and buffer overflow, and offers high-speed, low-cost interprocessor communication for SIMD computers.