Sun Oracle Exadata V2 For OLTP And DWH

Editor's Notes

• #7: Need 3 performance related quotes
• #16: The Sun Oracle Database Machine Full Rack combines Sun Oracle Exadata Storage Servers with Oracle Database in a complete pre-optimized and pre-configured package of software, servers, and storage. Simple and fast to install, the Oracle Database Machine is ready to start tackling your business queries immediately out-of-the-box . The Sun Oracle Database Machine Full Rack is a building block and you can add more racks as your data warehouse grows. The Sun Oracle Database Machine Full Rack consists of 8 Database Servers 14 Sun Oracle Exadata Storage Servers 3 InfiniBand switches 1 Gigabit Ethernet switch KVM Oracle is the first point of contact for all hardware & software issues and will manage the problem to resolution.
• #19: Infiniband throughput is based on 22 servers with one dual port 40 Gb/sec card per server.
• #20: 14 Exadata cells 168 disk drives 64 database server cores total 3 36-port Infiniband QDR (40Gb/sec) switches Enough for adding up to 7 more racks by just adding cables between the racks Cisco Ethernet 48-port switch (admin) KVM
• #45: Archival Compression Best approach for ILM and data archival Use on complete tables or combine with OLTP compression using partitioning Minimal storage footprint Data is always online and always accessible No need to move data to tape or configure multiple disk tiers Run queries against historical data (without recovering from tape) Update historical data Supports schema evolution (add/drop columns, indexes, etc.) Benefits any application with data retention requirements
• #46: Compression ratios based on Hybrid Columnar Compression “Query Default” and “Archive High”
• #50: Note that Enterprise Storage Arrays now support flash disks but there are no reported IOPs numbers from any vendor for their storage array using flash. The I/O performance numbers shown here are measured at the database level, not pure storage statistics that cannot be achieved in practice. Some vendors quote component level performance numbers that cannot be achieved in a complete systems due to bottlenecks at other parts of the system. Also, remember that this is a full system including servers, storage, and networking, not a pure storage device when comparing to other products. I/O rates are
• #52: Why is Oracle Faster DB Processing in Storage Smart Flash Cache Faster Interconnect (40Gb/sec) More Disks Faster Disks (15K RPM)
• #53: TPC-H 1TB, 11gR1 on Superdome (04/29/09) 64 cores, 768 disks (146GB 15K RPM) In-memory execution algorithms cache partitions in memory on different DB nodes Parallel servers (aka PQ Slaves) are then executed on the corresponding nodes
• #56: Because ASM is a volume management and file system component within the database it is designed to provide a file management layer optimized for the database. ASM optimizes performance by striping and optionally mirroring files across all the disks under its management. Additionally, ASM provides the ability to alter the storage configuration by adding or removing disks under its management without requiring the database down to be taken down. Finally, ASM is cluster-aware supporting RAC as well as multiple databases under a single ASM domain.
• #57: A Cell Disk is the virtual representation of the physical disk, minus the System Area LUN (if present), and is one of the key disk objects the administrator manages within an Exadata cell. A Cell Disk is represented by a single LUN, which is created and managed automatically by the Exadata software when the physical disk is discovered. On the first two disks, approximately 13GB of space is used for the system area. On the the other 10 disks, the system area is approximately 50MB. Cell Disks can be further virtualized into one or more Grid Disks. Grid Disks are the disk entity assigned to ASM, as ASM disks, to manage on behalf of the database for user data. The simplest case is when a single Grid Disk takes up the entire Cell But it is also possible to partition a Cell Disk into multiple Grid Disk slices. Placing multiple Grid Disks on a Cell Disk allows the administrator to segregate the storage into pools with different performance or availability requirements. Grid Disk slices can be used to allocate “hot”, “warm” and “cold” regions of a Cell Disk, or to separate databases sharing Exadata disks. For example a Cell Disk could be partitioned such that one Grid Disk resides on the higher performing portion of the physical disk and is configured to be triple mirrored, while a second Grid Disk resides on the lower performing portion of the disk and is used for archive or backup data, without any mirroring. Using ASM, you create Diskgroups from the Grid Disks and from that point on the Exadata Storage is transparent to the rest of the database and applications.
• #58: Exadata is able to extend the benefits of IDP to multiple grid disks on a single physical disk. The Grid disks are optionally split and interleaved such that frequently accessed data on all the grid disks are on the higher performing portions of the outer tracks. This ensures that all the applications benefit from the higher performance of the outer tracks of the physical disks.
• #59: For each disk group, ASM automatically creates a failure group for each Exadata Storage Server, containing the Grid Disks that belong to that server. ASM then mirrors the data such that the mirror copies are on a different failure group and hence a different Exadata Storage Server. That way, ASM is able to protect the database from disk failure and the failure of an Exadata Storage Server.
• #61: An Exadata administrator can create a resource plan that specifies how I/O requests should be prioritized. This is accomplished by putting the different types of work into service groupings called Consumer Groups. Consumer groups can be defined by a number of attributes including the username, client program name, function, or length of time the query has been running. Once these consumer groups are defined, the user can set a hierarchy of which consumer group gets precedence in I/O resources and how much of the I/O resource is given to each consumer group. This hierarchy determining I/O resource prioritization can be applied simultaneously to both intra-database operations (i.e. operations occurring within a database) and inter-database operations (i.e. operations occurring among various databases). In data warehousing, or mixed workload environments, you may want to ensure different users and tasks within a database are allocated the correct relative amount of I/O resources. For example you may want to allocate 50% of I/O resources to interactive users on the system, 30% of I/O resources to batch reporting jobs, and 20% of the I/O resources to the ETL jobs. This is simple to enforce using the DBRM and I/O resource management capabilities of Exadata storage. When Exadata storage is shared between multiple databases you can also prioritize the I/O resources allocated to each database, preventing one database from monopolizing disk resources and bandwidth to ensure user defined SLAs are met. For example you may have two databases sharing Exadata storage Assume that the business objectives dictate that database A should receive 33% of the total I/O resources available and that database B should receive 67% of the total I/O of resources. To ensure the different users and tasks within each database are allocated the correct relative amount of I/O resources various consumer groups are defined. For database A, 60% of the I/O resources are reserved for interactive marketing and 40% of the I/O resources are allocated for batch marketing activities. For database B. assume that 30% of the resources are allocated for interactive sales activities and 70% of the I/O resources are allocated fo the batch sales activities. These consumer group allocations are relative to the total I/O resources allocated to each database.
• #62: Instance Caging is very useful for consolidation. We want to support the consolidation of a large number of databases onto a grid, but make sure they share the server resources effectively. In the past, Resource Manager only worked inside a single database instance, but now it works between instances. No one database can usurp the resources of the entire server. This makes managing a consolidated environment much more easily. Can be dynamically set, with some limitations.
• #69: Active Data Guard sends copies of the redo log files to a remote database that applies them continuously. With Active Data Guard, the remote database can be either a physical or a logical standby database. New in 11gR2 is the ability of Active Data Guard to bi-directionally recover from block corruption.
• #71: Exadata also has been integrated with the Oracle Enterprise Manager (EM) Grid Control to easily monitor the Exadata environment. By installing an Exadata plug-in to the existing EM system, statistics and activity on the Exadata Storage Server can be monitored and events and alerts can be sent to the administrator. The advantages of integrating the EM system with Exadata include: Monitoring Oracle Exadata storage Gathering storage configuration and performance information Raising alerts and warnings based on thresholds set Providing rich out-of-box metrics and reports based on historical data All the functions users have come to expect from the Oracle Enterprise Manager work along with Exadata. By using the EM interface, users can easily manage the Exadata environment along with other Oracle database environments traditionally used with the Enterprise Manager. DBAs can use the familiar EM interface to view reports to determine the health of the Exadata system, and manage the configurations of the Exadata storage. Exadata Storage Servers provide a comprehensive Command Line Interface (CLI) to configure, monitor, and administer the server. In addition, a distributed version of the CLI utility is provided so that commands can be sent to multiple servers to ease the management of multiple servers. Each Exadata Storage Server has ILOM functionality to perform remote hardware administration tasks, like power cycling the servers.
• #72: Exadata also has been integrated with the Oracle Enterprise Manager (EM) Grid Control to easily monitor the Exadata environment. By installing an Exadata plug-in to the existing EM system, statistics and activity on the Exadata Storage Server can be monitored and events and alerts can be sent to the administrator. The advantages of integrating the EM system with Exadata include: Monitoring Oracle Exadata storage Gathering storage configuration and performance information Raising alerts and warnings based on thresholds set Providing rich out-of-box metrics and reports based on historical data All the functions users have come to expect from the Oracle Enterprise Manager work along with Exadata. By using the EM interface, users can easily manage the Exadata environment along with other Oracle database environments traditionally used with the Enterprise Manager. DBAs can use the familiar EM interface to view reports to determine the health of the Exadata system, and manage the configurations of the Exadata storage. Exadata Storage Servers provide a comprehensive Command Line Interface (CLI) to configure, monitor, and administer the server. In addition, a distributed version of the CLI utility is provided so that commands can be sent to multiple servers to ease the management of multiple servers. Each Exadata Storage Server has ILOM functionality to perform remote hardware administration tasks, like power cycling the servers.
• #75: This is all about scale out. Scale outwards !