virtualization options m series 168435

8/7/2019 Virtualization Options M Series 168435

http://slidepdf.com/reader/full/virtualization-options-m-series-168435 1/19

An Oracle White Paper

September 2010

Virtualization Options for Oracle Database Deployments

on Sun SPARC Enterprise M-series System



Oracle White Paper—Virtualization Options for Oracle Database Deployments on Sun SPARC Enterprise M-Series Systems

Introduction ......................................................................................... 2Overview of Sun SPARC Enterprise M-series Systems ..................... 2Dynamic Domains............................................................................... 3

Creating Dynamic Domains and Dynamic Reconfiguration ............ 6System Monitoring and Control....................................................... 9

Oracle Solaris Containers ................................................................. 11Oracle Solaris Resource Manager .................................................... 12Deploying Oracle Database on the Oracle Solaris Platform............. 13

Proven Performance and Scalability............................................. 13Predictive Self-healing: Enhanced Availability .............................. 14User Rights Management: Enhanced Security ............................. 14DTrace: Enhanced Observability .................................................. 15Enhanced System V IPC implementation: Ease of Deployment... 15

Conclusion ........................................................................................ 16References........................................................................................ 17




2

Introduction

The combination of Sun SPARC Enterprise M-series systems and Oracle Solaris 10 provides an ideal

platform for Oracle Database deployments. The Oracle Solaris Operating System delivers built-in

virtualization capabilities across the entire M-series server line in addition to enterprise-class

performance, reliability, availability, serviceability, and security. On top of the capabilities provided by

the Oracle Solaris Operating System, the M4000, M5000, M8000 and M9000 servers all feature

virtualization capabilities granting full hardware isolation of Dynamic Domains. The ability to

virtualize at both the Dynamic Domain layer as well as at the operating system layer within each

domain offers industry leading flexibility.

This document is intended for IT professionals who want to understand the benefits of deploying

Oracle databases on Sun SPARC Enterprise M-series systems.

Overview of Sun SPARC Enterprise M-series Systems

Oracle offers a variety of Sun SPARC Enterprise M-series systems, ranging from the single socket

M3000 to the 64 socket M9000-64. Running the Oracle Solaris Operating System, all feature

mainframe-class reliability, availability and serviceability features such as predictive self-healing and hot

swap components for maximum availability. While even the M3000 has considerable virtualization

flexibility with up to 8191 Oracle Solaris Containers, the M4000 and larger systems also feature from 2

to 24 Dynamic Domains each, granting the ability to partition hardware resources into smaller logical

systems. Each Dynamic Domain runs its own copy of the Oracle Solaris Operating System, and

hardware resources may be moved between Dynamic Domains without so much as requiring a reboot

or even restarting an Oracle 11gR2 Database. Each Dynamic Domain in turn is capable of running a

few to thousands of virtualized operating system instances using Oracle Solaris Containers.

In addition to the complete hardware isolation of Dynamic Domains and the operating system

virtualization of Oracle Solaris Containers, Oracle Solaris Resource Manager can be used to more

precisely control resources available to multiple applications running in a single OS instance with a

minimum of administrative effort. Solaris Resource Manager operates on a project , task, or container

level so can be applied to an entire container, applications within a container, or to applications even

when containers are not in use.

Virtualization options exist to meet a broad spectrum of needs. On one end of that spectrum,

Dynamic Domains provide electrically isolated partitions so hardware or software errors in one domain

do not affect others, but offer the finest control level of a physical processor, a group of memory

DIMMs, and a single IO board. On the other extreme, Oracle Solaris Resource Manager offersresource controls which can specify CPU resources in fractions and memory resources in smaller

amounts such as megabytes without the need to administer another operating system. In between

these two extremes, Oracle Solaris Containers offer a lot of flexibility in resource control as well as the

isolation of virtual operating system instances.




3

Figure 1 illustrates the spectrum of isolation/flexibility for Dynamic Domains, Oracle Solaris

Containers, and Oracle Solaris Resource Manager:

Figure 1 : Spectrum of Isolation and Flexibility for virtualization options

Dynamic Domains

One of the key features of the Sun SPARC Enterprise M-series servers is the ability to partition theavailable hardware resources into smaller logical systems called Dynamic Domains. Dynamic Domains

run their own copies of the operating system and offer a very high level of isolation from other

domains in the system because the partitioning occurs at the hardware level. Additionally, the amount

of hardware resources in a domain can be changed when needed through Dynamic Reconfiguration

while the operating system and applications like the Oracle 11gR2 Database continue to run. Domain

reconfiguration typically takes only a few minutes. During this reconfiguration, applications continue

to operate without disruption by utilizing the resources that are not transitioning in or out of the

domain.

The underlying goal of Dynamic Reconfiguration is to allow organizations to gain higher hardware

utilization of their servers while achieving greater resiliency against hardware failures. The architecture

allows for components within the server (CPUs, memory, I/O resources) to be assigned, reserved, and

moved between different Dynamic Domains. The need to move components can come from business

needs - like dynamic provisioning if loads during certain times of day or week require more resources

in some Domains - or from the need to replace faulty or failed hardware.




4

Dynamic Domains represent logical partitions within the server chassis, allowing for separation of

resources and allowing multiple instances of the Oracle Solaris Operating System to run concurrently

on the system. Each instance of the Oracle Solaris OS running in its Dynamic Domain has access to its

own resources, providing complete isolation of one Oracle Solaris instance from any other instance

running on the same server.

As each Dynamic Domain runs an independent operating system, it is protected by hardware and is

not affected by other domains. For example, even an extreme software problem like an operating

system panic in one domain will not affect other domains. More commonly, an operating system in

one domain can be rebooted or reinstalled without affecting other domains. Also, each domain can

run a different operating system version or patch level if desired.

Dynamic Domains were first introduced in the Sun Enterprise™ 10K server, but the Sun SPARC

Enterprise M-series (M4000 and larger) servers use a more flexible design that allows much finer-

grained resource allocation.

All Sun SPARC Enterprise M-series systems use SPARC64 processors. Each physical processorcurrently is composed of two or four cores, and each core in turn has two hardware threads. Hardware

threads, referred to throughout this paper as CPU threads, are what the system administrator observes

using tools like psrinfo(1M). The term CPU is used throughout this paper to refer to a physical

processor.

A domain can be as small as one dual- or quad-core processor, four or eight memory DIMMs, and two

PCIe slots. A domain can be as large as 256 cores, 4 TB RAM, and 128 PCIe slots on the Sun SPARC

Enterprise M9000-64 server. Or just about anything in between. CPU, memory, and IO resources can

be moved between domains while the operating systems are running. Additionally, all Sun SPARC

Enterprise systems support hot swap and dynamic reconfiguration of I/O. Sun SPARC Enterprise

M8000 and M9000 servers also support hot swap of CPUs and memory. Hot swap allows removing,

replacing, or adding resources to any domain without the need to reboot Solaris, or even stop a

running instance of an Oracle 11gR2 database.

Dynamic Domains are composed of two types of boards: CPU/memory boards and I/O boards

containing a number of PCIe slots and/or disks. Both of these board types connect to a central data

and address switch. A server partition, called a domain, is created by grouping at least one

CPU/memory board and at least one I/O board. The interconnect can then be reconfigured to allow

communication between the boards only in the same domain. Once this configuration is done, the

boards are isolated from boards in any other domain.

The maximum number of domains that a system can be partitioned into depends upon the size of the

system and the available resources. A Sun SPARC Enterprise M4000 server can have a maximum of

two domains, while the Sun SPARC Enterprise M5000 server can support up to four. The Sun SPARC

Enterprise M8000 and M9000 servers support up to 16 and 24 domains respectively.

As a simple example of how to use Dynamic Domains, Figure 2 shows a high level view of an M5000

server configured with two domains used for production and development, each having equal CPU

and memory resources. The production domain executes an enterprise application and the




5

development domain is used to test experimental changes. Fully populated with quad-core CPUs and

2GB DIMMs, each domain has 32 CPU threads and 64GB RAM. The darker shading around CPUs

7/8 and two memory boards is to highlight the plan to move these at a later time:

Figure 2 : High level view of an M5000 with two evenly distributed domains

In Figure 3, two CPU sockets (16 CPU threads) and two Memory boards (32 GB RAM) have been

moved from the Development Domain to the Production Domain to speed up an after hours Oracle

Database batch job requiring significantly more CPU and memory resources. Operating systems and

applications including the Oracle databases continued to run in each domain throughout the

reconfiguration:

Figure 3 : High level view of an M5000 after dynamically moving resources




6

Many other configuration options exist for the M5000, with up to 4 domains. Higher end M-series

servers have far more flexibility, with up to 24 domains available.

Creating Dynamic Domains and Dynamic Reconfiguration

Sun SPARC Enterprise M4000/M5000/M8000/M9000 servers have a unique partitioning feature

which allows one physical system board to be utilized as one logical system board, or to be divided into

four logical system boards, creating either a simple or a flexible configuration depending upon the

needs and available resources. These logical system boards can be easily combined to create Dynamic

Domains using the system monitoring and control facility.

Dynamic Reconfiguration enables hardware resources such as logical system boards, processors,

memory, and I/O devices to be added to, or removed from Dynamic Domains even while the Oracle

Solaris Operating System and applications such as Oracle Database 11gR2 are running.

Dynamic Reconfiguration has three basic functions: add, delete, and move. These can be used to:

• Add system boards to a domain without stopping Oracle Solaris, to improve business operations or

to handle higher system loads.

• Temporarily remove a faulty system board for parts replacement without stopping Oracle Solaris or

applications running in the domain, in the event of an error that causes the system board to become

degraded.

• Move a resource from one domain to another while continuously operating the domains without

physically removing or inserting a system board. Resources can be moved to balance the loads on

multiple domains, or to share common I/O resources between domains.

Figure 4 shows an example of dynamic reconfiguration on an M5000 configured with two domains.The three stages are each illustrated by a System Monitoring and Control terminal and a Production

Domain shell terminal. Both Production and Development Domains are running Oracle Solaris, and

the Production Domain has 32 CPU threads and 64 Gigabytes of RAM:




8

And, of course, dynamically moving resources between running domains requires the ability to also

remove resources while Oracle Solaris is running. Figure 6 shows the removal of just one CPU and

one memory board, resulting in a CPU thread count of 40 with 80 Gigabytes of RAM available; also

captured are the date and uptime so it is clear the OS has been running (along with an Oracle 11gR2

Database and other applications in this Solaris instance) without interruption as all this reconfiguration

was taking place:

Figure 6 : Commands to remove resources and CPU/memory availability after removal

Many more options are available to reassign resources between two running domains on an M5000,

with as few as 4 and as many as 56 CPU threads. Additionally, hard drives and PCIe slots/devices can

be dynamically moved between running domains, though each domain must contains a boot drive or

bootable PCIe device. For simplicity the above examples show only two domains; however, up to four

domains can be concurrently running and dynamically reconfigured on an M5000.

Most applications running on a domain will immediately benefit from dynamically added resources

(CPU and memory). Oracle Solaris immediately starts scheduling processes on new CPU threads and

distributes the new memory pages to processes that request them. No administrator action is required.

Applications which use a shared memory segment are an exception. These applications confine their

memory usage to this segment. To enable a dynamically adjustable amount of shared memory for

applications, version 8 and later of the Oracle Solaris OS and Oracle Database 9i and later releasessupport Dynamic Intimate Shared Memory (DISM).

A DISM segment can be created with a size that is larger than the amount of physical memory in the

system. If this is the case, the segment cannot be locked in memory at creation time. A process that

makes use of a DISM segment can lock and unlock parts of the segment while the process runs. By




9

doing so, the application can effectively react to the addition of physical memory to the system or

prepare for removal of memory.

All Oracle Database processes that make up a database instance share one large memory segment

called the System Global Area (SGA). Internally, chunks of this memory are used for distinct purposes,like the redo log buffer and the shared pool.

With the release of Oracle Database 9i, it has been possible to change the size of these components

without having to shut down the instance, as long as the sum of their sizes does not exceed the size of

the initially created SGA. This initial size cannot be changed without shutting down the database

instance.

With DISM, the SGA can be created larger than the amount of physical memory in the system, so that

memory added to the system can later be used by the running database instance. As of Oracle

Database 11gR2, DISM is now the default. Using Solaris Reconfiguration Coordination Manager, it is

possible to have scripts alert the Oracle 11gR2 Database when CPUs/memory are to be removed from

a Dynamic Domain so it can dynamically scale the SGA down to allow a board to be removed withoutshutting down the database.

System Monitoring and Control

A system monitoring and control facility, independent of the server processors, constantly monitors

the server and provides an interface between the system administrator and the server to configure and

control domains.

Commonly referred to as the eXtended System Monitoring and Control Facility, XSCF, this

centralized management of hardware configuration, control of hardware monitoring, cooling system

monitoring, domain status monitoring, and error monitoring further ensures high system availability.

For increased reliability, the SPARC Enterprise M8000 and M9000 servers have options available forredundant system monitoring and control facilities.

Adding Resources to a Domain

Dynamic Reconfiguration can be used to add a system board to a domain provided that board is

installed in the system and not assigned to another domain. This can be accomplished without

stopping the Oracle Solaris OS running in the domain. A system board is added in stages via connect,

and configure. In the add operation, the selected system board is connected to the target domain.

Then, the system board is configured to the Oracle Solaris OS of the domain. At this point, addition

of the system board is completed.

Removing Resources from a Domain

Dynamic Reconfiguration can be used to delete a system board from a domain without stopping the

Oracle Solaris OS running in that domain. A system board is deleted in stages with unconfigure and

disconnect. If the board must be assigned to another domain, the delete operation must also include an

unassign step. In the delete operation, the selected system board is unconfigured from its domain by




10

the operating system. Then, the board is disconnected from the domain. At this point, deletion of the

system board is completed.

Moving Resources from one Domain to Another

Dynamic Reconfiguration can be used to reassign a system board from one domain to another without

stopping the Oracle Solaris OS running in either domain. This move function can change the

configurations of both domains without physical removal and remounting of the system board. The

move operation for a system board is a serial combination of the “delete” and “add” operations. In

other words, the selected system board is deleted from its original domain and then added to the target

domain.

Replacing a Resource in one Domain

Dynamic Reconfiguration can also be used to remove a system board from a domain and either add it

back later, or replace it with another system board, provided both boards satisfy dynamic

reconfiguration requirements. This can be done without stopping Oracle Solaris in either domain. Anexample of this replacement of a system board would be exchanging hardware resources such as CPUs,

memory, or I/O devices. A system board is replaced successively in stages. In the replace operation,

the selected system board is deleted from the OS of the domain. Then, the system board is physically

removed when it is ready to be released from its domain. After parts replacement, the system board is

re-installed and added.

Some useful board designations:

• Any logical system board can be designated as a “float” board. Boards so designated are considered

as the lowest priority for holding kernel memory, and are thus easier to dynamically reconfigure out

of domains. By designating system boards as float boards, resources can be moved more easily from

idle domains to busy domains.• Any logical system board can be reserved for use in a specific domain. This capability is helpful if

limitations exist for using live Dynamic Reconfiguration to move resources into a running domain

(such as per-CPU application licensing). Boards that are reserved for the domain are configured and

available for processing upon the next reboot.

• Any system board can have either “Omit Memory” and/or “Omit I/O” attributes set. Boards so

designated will not add their memory or I/O devices into the domain to which they have been

configured. This capability simplifies system administration decisions regarding dynamic

reconfiguration operations since the domain ignores the memory and input / output devices on the

logical system board. As a result, dynamic reconfiguration of logical system boards into and out of

domains can be accelerated with these options.

While Dynamic Domains provide a great deal of flexibility in assigning resources to an operating

system, if finer grained resource allocation is needed within one domain, Oracle Solaris Containers can

be used to further subdivide resources while still maintaining many OS isolation features. Within one

of those containers, Oracle Solaris Resource Manager can be used to further control resource

allocation with even finer granularity but less isolation.




11

Oracle Solaris Containers

Oracle Solaris Containers provide additional flexibility in virtualizing operating system instances, while

still providing many of the same isolation features of Dynamic Domains.

Operating System virtualization with Oracle Solaris Containers allows you to maintain the one-

application-per-server deployment model while simultaneously sharing hardware resources. An integral

part of the Oracle Solaris 10 Operating System, Oracle Solaris Containers isolate software applications

and services using flexible, software-defined boundaries and allow many private execution

environments to be created within a single instance of Oracle Solaris 10. Each environment has its own

identity, separate from the underlying hardware. Each behaves as if it is running on its own operating

system making consolidation simple, safe, and secure.

The number of containers on a system is limited in practice only by memory and disk space, though

currently a maximum of 8191 containers can be created for a single operating system image. Each

container has a very small amount of CPU and memory overhead, far less than that of a typical

hypervisor-based operating system instance. Unlike Dynamic Domains, Oracle Solaris Containers do

not restrict CPU and memory resource associations, so an execution environment can allocate many

CPUs but limited memory, a lot of memory but few CPUs, or a more balanced pool of resources. Also

unlike Dynamic Domains, fractions of CPUs can be used as well as whole CPUs, and memory can also

be specified in smaller amounts such as megabytes.

Oracle Solaris Containers can all share CPU resources, can each have dedicated CPU resources, or can

each specify a guaranteed minimum amount of resources as well as a maximum. Memory can be

shared among all Oracle Solaris Containers, or each can have a specified memory cap. Physical I/O

resources such as disk and network can be dedicated to individual Oracle Solaris Containers, shared by

some, or shared by all. Regardless of what is shared or dedicated, each virtualized environment will

have isolated access to local file system and networking, as well as system and user processes.

Oracle Solaris Containers are ideal for the consolidation of environments. With the increasing cost

and complexity of managing many separate systems, or even the larger granularity of Dynamic

Domains, it is often advantageous to consolidate multiple applications onto larger, more scalable

servers. Oracle Solaris Containers provide more efficient resource utilization with a reduced number of

systems.

Dynamic resource reallocation permits unused resources to be shifted to other Oracle Solaris

Containers as needed. Security and fault isolation mean that poorly behaved applications no longer

require a dedicated and often under-utilized system. With the use of Oracle Solaris Containers, these

applications can be safely and securely consolidated with other applications. This allows system

administrators to delegate some administrative functions while maintaining overall system security.

Extending the previous example of an M5000 configured with two Dynamic Domains, the Production

Domain may also use Oracle Solaris Containers, one for an Oracle 11gR2 Database, and another for an

Application Server. Each has its own file system and network identity which can be attached to shared

or separate physical storage and network ports, and each is granted half of the CPU and memory of

that domain. In this example, the company has six separate development groups as well as a QA group.




12

The Development Domain uses seven Oracle Solaris Containers. The development teams share the

same physical storage and network ports but maintain isolated file systems and network identity. Each

container in the Development Domain is allocated a minimum of two and a maximum of eight CPU

threads, and each has memory capped at 9GB RAM so that no one group can starve any other of

needed CPU or memory resources. The licensing model of Oracle 11gR2 Database is aligned such that

the use of Oracle Solaris Containers with CPU resource control can provide cost containment. Please

contact your local Oracle sales partner for further details.

If CPU resource distribution needs to be controlled with finer granularity than a CPU thread, CPU

resources can be specified in shares (which are used to express a ratio and can add up to as big a

number as one chooses).

For more complete hardware level isolation and greater fault isolation, as well as to host different

operating system versions or different patch set levels, M-series Dynamic Domains may be a better

match, but Oracle Solaris Containers can be created and hosted on top of these environments for even

greater control over resource utilization.

For more information about Oracle Solaris Containers please see "System Administration Guide:

Solaris Containers-Resource Management and Solaris Zones" on http://docs.sun.com.

Oracle Solaris Resource Manager

The Oracle Solaris Resource Manager is a resource control mechanism that provides the ability to

allocate and control major system resources such as CPU, network bandwidth, and memory of various

users or applications. This ability, as with Oracle Solaris Containers, enables the consolidation of

multiple applications onto a single server thus improving the resource utilization and lowering the

Total Cost of Ownership (TCO). Control of CPU, Memory, and other resources is as fine grained as

with Oracle Solaris Containers, but can be applied to users, or projects rather than an entire container.

To guarantee predictable service levels, Solaris Resource Manager implements administrative policies

that govern the resources that different users or applications can access, and more specifically, the level

of consumption of those resources that each user or application is permitted. In other words, using

Solaris Resource Manager, system administrators can define workloads, partition and allocate system

resources to different entities in such a way that pre-defined Service Level Agreements are met while

maintaining the overall quality of service and keeping the system resources busy. In addition, Solaris

Resource Manager facility allows administrators to monitor resource usage, so they can identify users

or applications that tend to use more resources than they should, and to compile more accurate data

over time for capacity planning and billing purposes.

Even further extending the previous example of an M5000 configured with two Dynamic Domainsand the Development Domain subdivided into seven Oracle Solaris Containers, suppose that the QA

team assigned to a container finds that one set of regression tests can sometimes consume all the CPU

resources allocated to their entire container. The QA team might determine that the best way to allow

their other testing to complete is to create a project specifying capped-cpu with the number of CPUs

set to 0.5, then run this set of regression tests assigned to that project group.




13

The basic building blocks of Solaris Resource Manager are tasks, projects and resource controls.

Oracle Solaris Resource Manager facilitates establishing resource limits on a per-process, per-task and

per-project basis.

A "task" is a collection of related processes, and a "project" is an administrative identifier that is usedto identify related work or to classify a service such as a database instance. A "project" may consist of

one or more "tasks" that represent a workload. That is, a "workload" is an aggregation of all processes

of an application or group of applications. Every process that runs in the system is associated with a

"project" and a "task".

A "resource control" dictates how the Oracle Solaris Operating System will manage the controlled

resource as well as how the system will react when the imposed resource limit has been reached. For

example, a system administrator at a university can limit the number of threads in each task to 50 for

all tasks in a project that was created for all undergraduate students, and instruct the OS to kill such

tasks when the established limit has been reached. This would help prevent runaway processes from

exhausting system resources and in bringing the system to a complete halt.

For more information about the Oracle Solaris Resource Manager and the underlying technology,

please refer to the "Resource Management" section in "System Administration Guide: Solaris

Containers-Resource Management and Solaris Zones".

Deploying Oracle Database on the Oracle Solaris Platform

The Oracle Solaris Operating System delivers enterprise-grade performance, massive scalability,

virtualization, and security. It runs across the entire range of Sun SPARC and x86 platforms from

entry level servers to 64-processor servers like the Sun SPARC Enterprise M9000 server. Not only

does the Oracle Solaris Operating System scale across systems of different sizes, it scales across

different technologies and hardware platforms by delivering binary compatibility within the SPARCand x86 processor families.

The Oracle Solaris 10 Operating System introduced new features to enhance manageability,

performance and availability to unprecedented levels. The key new features include Oracle Solaris

Containers for virtualization, Predictive Self-healing, DTrace for advanced observability, ZFS for next-

generation volume management and file system support, and user and process rights management. An

Oracle database deployment can take advantage of each of these unique features found in Oracle

Solaris 10 to enhance the manageability, scalability, availability and security of both single and multiple

Oracle database instances – all across multiple platform and processor architectures.

Proven Performance and Scalability

The Oracle database has a proven track record of scaling well both vertically as well as horizontally on

the Solaris 10 platform. Oracle Database 11gR2 with Oracle Real Application Clusters demonstrated

excellent horizontal scalability across 12 Sun SPARC Enterprise T5440 servers on Solaris 10 running

the industry-standard TPC-C workload. The Oracle database also scaled well on a single Oracle Sun

SPARC Enterprise M9000 running the industry-standard TPC-H data warehousing benchmark. Oracle




14

Database 11gR2 provides options for customers to use scalability in both horizontal and vertical

dimensions to best meet their critical performance and availability criteria.

Predictive Self-healing: Enhanced Availability

The Oracle Solaris Operating System has implemented predictive self-healing for CPU, memory, and

I/O bus nexus components for a variety of hardware platforms incorporating SPARC, AMD Opteron

and Intel Xeon processors, exploiting the specific hardware RAS features provided by the underlying

system. Additionally, the Oracle Solaris Operating System provides a platform neutral technology,

Memory Page Retirement (MPR), to ensure that both the Oracle Solaris Operating System and user

applications continue to operate in the face of main memory faults.

Oracle Solaris MPR technology ensures that Oracle database deployments can continue uninterrupted

even when the underlying system has memory errors. Consider the scenario of an Oracle database

instance deployed on a system that is experiencing memory errors. The diagnosis engine of the Oracle

Solaris fault manager, which is continuously examining both correctable errors (CEs) and

uncorrectable memory errors (UEs), will see a series of correctable errors in a memory location as an

indication of a potentially uncorrectable memory error. If the Oracle database has memory pages that

contain CEs then Oracle Solaris MPR will retire those pages from memory without interrupting Oracle

processes. If the Oracle database references memory pages that have uncorrectable memory errors,

then Oracle Solaris MPR will retire clean pages containing UEs, again without interrupting Oracle

processes. In the unlikely case of the Oracle database having dirty memory pages with UEs, the oracle

processes will come down. However, if the Oracle Database is configured with Service Management

Facility, as explained in the next section, it can restart automatically.

Adding the Oracle database and Oracle listeners as a service to the Solaris Service Management Facility

(SMF) provides the following advantages:

• Automatically restarts failed services in dependency order, whether they failed as the result of administrator error, a software bug, or were affected by an uncorrectable hardware error.

• Provides more information about misconfigured or misbehaving services, including an explanation

of why a service isn't running, as well as individual, persistent log files for each service.

• Delegates the task of managing the Oracle services to Oracle administrators -SMF is integrated with

Oracle Solaris Role Based Access Control (RBAC) which ensures that the services can be securely

managed by non-root users, including the ability to configure, start, stop, or restart services.

User Rights Management: Enhanced Security

Default installations of the Oracle database can be made more secure by exploiting the user rights

management feature of Oracle Solaris 10 security. In a typical Oracle deployment, all Oracle database

administrators (DBAs) login as UNIX user oracle. Hence, it is not possible to track the DBA-related

activities of an individual user; only the combined activities of all DBAs are tracked by the operating

system and the database server. User rights management enables you to create an oracle role and

assign it to users with DBA responsibilities. In this scenario, the users will login to the database server

system with their regular UNIX logins and assume the oracle role when they need to do any Oracle




15

DBA-related tasks. This approach ensures that multiple Oracle administrators do not share a single

login. They login in as individual user and are accountable for their individual actions; yet they have

the flexibility to perform all the functions of an Oracle administrator by assuming the oracle role.

Complete accountability for individual users can be enforced by enabling auditing of the oracle role;

which in turn will provide a detailed description all Oracle DBA-related activities for each individual

UNIX user.

DTrace: Enhanced Observability

With the advent of multi-tier architectures today's applications have become very complex. While

individual levels of the application tier may have excellent tools for observability and debugging, there

are no tools to observe and optimize the entire application stack. This problem becomes even more

complicated for observing applications in production which are likely sensitive to performance

impacts. Also, it is not always easy to stop and start these applications to enable debug flags. Adding

debug versions of applications into production may not be permitted. Even if permitted, bringing

debug versions into production involves expensive and time consuming QA cycles. All of these issuescomplicate the problem of observation.

DTrace, a Dynamic Tracing framework, was developed to address this very problem. It can be used to

observe any or all tiers of the application stack, is truly dynamic, and does not require application code

changes or even an application restart. One can observe fully optimized applications using DTrace.

The overhead of observation is low and there is no overhead when observation is turned off.

Instrumentation can be turned on and off dynamically thus only collecting information when it is

needed. DTrace is safe and turns itself off when observation overhead affects system performance.

DTrace can be used to observe applications developed in, C, C++, Java, JavaScript, Ruby, PHP, Perl,

Python among other programming and scripting languages. Other system layers, like I/O, networking,

application and kernel locks, CPU counters etc, can also be observed using DTrace.DTrace scripts are used to enable and program points of instrumentation. D-script format does not

change based on the application tier being observed and a single script can be used to observe multiple

tiers at the same time.

DTrace can be used to look at Oracle database processes in isolation or concurrently with any other

processes running on the system and can be an invaluable tool for identifying performance bottlenecks

and many other real world issues.

Enhanced System V IPC implementation: Ease of Deployment

Prior to Oracle Solaris 10, installing the Oracle database on the Oracle Solaris Operating System

required changes to the /etc/system file. Every reconfiguration required a reboot for the changes totake effect. However, the System V IPC implementation in Solaris 10 no longer needs changes to the

/etc/system file. Instead, the new resource control facility is used, which allows changes to become

effective immediately, without a system reboot. Furthermore, the default settings of the System V IPC

parameters have been set to typical defaults enabling Oracle database instances to run out-of-the-box

without requiring special parameters to be set.




16

Oracle database deployments on Oracle Solaris 10 work out of the box, with no additional system

configuration, if the System Global Area (SGA) uses less than 25% of the system's total memory. If the

deployment plans to use more than 25% of the systems memory, then the shared memory resource

parameter can be dynamically set to the required value using the resource control facility.

Conclusion

Sun SPARC Enterprise M-series systems running Oracle Solaris 10 provide ideal platforms for Oracle

11gR2 Database deployments, with powerful virtualization options. The Oracle Solaris Operating

System delivers built-in virtualization capabilities across the entire M-series server line in addition to

enterprise-class performance, reliability, availability, serviceability, and security. On top of the

capabilities provided by the Oracle Solaris Operating System, the M4000 and larger servers all feature

virtualization capabilities granting full hardware isolation of Dynamic Domains. The ability to

virtualize at the Dynamic Domain layer – and at the operating system layer within each domain, in

addition to the ability to control resource utilization with Solaris Resource Manager provides a broad

range of options not available on other platforms.




17

References

• Sun SPARC Enterprise M4000/M5000/M8000/M9000 Servers Dynamic Reconfiguration (DR)

User Guide

• Sun SPARC Enterprise M4000/M5000/M8000/M9000 Servers XSCF Reference Guide

• Introduction to Dynamic Reconfiguration and Capacity on Demand for Sun SPARC Enterprise

Servers

• Sun SPARC® Enterprise M8000/M9000 Servers Service Manual

• Deploying Oracle Database on the Solaris Platform

• Best Practices for Running Oracle Databases in Solaris Containers

• System Administration Guide: Solaris Containers-Resource Management and Solaris Zones

• Sun SPARC® Enterprise Series Servers Configuration Concepts

virtualization options m series 168435

Documents