Skip Headers
Oracle® Database Platform Guide
11g Release 1 (11.1) for Microsoft Windows

B32010-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

1 Oracle Database Architecture on Windows

This chapter describes how Oracle Database architecture takes advantage of some of the more advanced services in Windows operating systems.

This chapter contains these topics:

Oracle Database on Windows Architecture

Oracle Database on Windows is a stable, reliable, and high performing system upon which to build applications. Each release of the database provides new platform-specific features for high performance on Windows.

Oracle Database operates the same way on Windows as it does on other platforms. The architecture offers several advantages on Windows, such as:

Automatic Storage Management

Automatic Storage Management (ASM) is an integrated file system and volume manager expressly built for Oracle Database files. ASM provides the performance of raw I/O with the easy management of a file system. It simplifies database administration by eliminating the need for you to directly manage potentially thousands of Oracle Database files. It does this by enabling you to divide all available storage into disk groups. You manage a small set of disk groups, and ASM automates the placement of the database files within those disk groups.

See Also:

"Using Automatic Storage Management" in Oracle Database Administrator's Guide

Thread-Based Architecture

The internal process architecture of Oracle Database is thread-based. Threads are objects within a process that run program instructions. Threads allow concurrent operations within a process so that a process can run different parts of its program simultaneously on different processors. A thread-based architecture provides the following advantages:

  • Faster context switching

  • Simpler System Global Area allocation routine, because it does not require use of shared memory

  • Faster spawning of new connections, because threads are created more quickly than processes

  • Decreased memory usage, because threads share more data structures than processes

Internally, the code to implement the thread model is compact and separate from the main body of Oracle Database code. Exception handlers and routines track and de-allocate resources. They add robustness, with no downtime because of resource leaks or an ill-behaved program.

Oracle Database is not a typical Windows process. On Windows, an Oracle Database or Automatic Storage Management instance (threads and memory structures) is a Windows service: a background process registered with the operating system. The service is started by Windows and requires no user interaction to start. This enables the database to open automatically at computer startup.

When running multiple Oracle Database or Automatic Storage Management instances on Windows, each instance runs its own Windows service with multiple component threads. Each thread may be required for the database to be available, or it may be optional and specific to certain platforms. The background processes read and write from various datafiles, depending on your configuration. Oracle Database architecture on Windows is illustrated in Figure 1-1. Examples of Oracle Database required threads on Windows are listed in Table 1-1.

Figure 1-1 Oracle Database Architecture on Windows

Description of Figure 1-1 follows
Description of "Figure 1-1 Oracle Database Architecture on Windows"

Table 1-1 Oracle Database Threads

Oracle Database Thread Description Required/Optional

DBW0

database writer

Required

LGWR

log writer

Required

MMAN

memory manager process

Required

PMON

process monitor

Required

PSPO

process spawner process

Required

SMON

system monitor

Required

CKPT

checkpoint process (thread on Windows) that runs by default on Windows

Required

ARCH0

archive process (or thread on Windows)

Required

RECO

distributed recovery background process

Required


Note:

You can view running background processes by issuing the following query:
SQL> select * from v$bgprocess where paddr <> '00'; 

Oracle Database for Windows is supplied as a set of executables and dynamic link libraries (DLLs). Executable images can be modified using ORASTACK to change the size of the stack used by the threads of the Oracle Database process. Oracle recommends you use this tool only under the guidance of Oracle Support Services.

File I/O Enhancements

Oracle Database supports 64-bit file I/O to allow use of files larger than 4 gigabytes (GB). In addition, physical and logical raw files are supported as data, log, and control files to support Oracle Real Application Clusters (Oracle RAC) on Windows and for those cases where performance needs to be maximized.

With Oracle Database 11g Release 1 (11.1), instead of using the operating system kernel NFS client, you can configure Oracle Database to access NFS V3 servers directly using an Oracle internal Direct NFS client. Through this integration, Oracle is able to optimize the I/O path between Oracle and the NFS server providing significantly superior performance. In addition, Direct NFS client simplifies and optimizes the NFS client configuration for database workloads.

Oracle Direct NFS Client currently supports up to four parallel network paths to provide scalability and high availability. Direct NFS Client delivers optimized performance by automatically load balancing requests across all specified paths. If one network path fails, then Direct NFS Client will reissue commands over any remaining paths ensuring fault tolerance and high availability.

See Also:

Your vendor documentation to complete NFS configuration and mounting.

Raw File Support

Oracle recommends that you use Automatic Storage Management instead of raw files. It provides the performance benefits of raw files with much better manageability. Automatic Storage Management is available for both single instance and Oracle RAC databases.

Raw files are unformatted disk partitions that can be used as one large file. Raw files have the benefit of no file system overhead, because they are unformatted partitions. Windows supports raw files, similar to UNIX. Using raw files for database or log files can have a slight performance gain. Windows 2000 and later has a disk manager (diskmgmt.msc) to manage all volumes. Windows 2003 and later includes command line utilities (diskpart.exe) to manage volumes including raw. Oracle recommends that you use Windows volume mount points for addressing raw volumes.

To Oracle Database, raw files are no different from other Oracle Database files. They are treated in the same way by Oracle Database as any other file and can be backed up and restored through Recovery Manager or OCOPY.

Note:

  • You must be logged on either as Administrator or a user name that is a member of the Administrators group.

  • To open Disk Management console, click Start, Run, and then type: diskmgmt.msc.

Oracle Database Scalability on Windows

Features in Oracle Database and in the Windows operating system work together to help increase scalability, throughput, and database capacity. These features include:

Support for Very Large Memory (VLM) Configurations

Oracle Database for Windows 32-Bit supports Very Large Memory (VLM) configurations, which allows Oracle Database to access more than the 4 gigabyte (GB) of RAM traditionally available to Windows applications. Specifically, Oracle Database uses Address Windowing Extensions (AWE) to access more than 4 GB of RAM.

Note:

  • This feature is available on Windows with Intel Pentium II and later processors.

  • VLM configurations are not supported on Windows x64.

The requirements for taking advantage of this support are:

  1. The computer on which Oracle Database is installed must have more than 4 GB of memory.

  2. The operating system must be configured to take advantage of Physical Address Extensions (PAE) by adding the /PAE switch in boot.ini. See Microsoft Knowledge Base article 268363 for instructions on modifying boot.ini to enable PAE.

  3. It is advisable (though not necessary) to enable 4GT support by adding the /3GB parameter in boot.ini. See Microsoft Knowledge Base article Q171793 for additional requirements and instructions on modifying boot.ini to enable 4GT.

  4. The user account under which Oracle Database runs (typically the LocalSystem account), must have the "Lock memory pages" Windows 2000 and Windows XP privilege.

  5. USE_INDIRECT_DATA_BUFFERS=TRUE must be present in the initialization parameter file for the database instance that will use VLM support. If this parameter is not set, then Oracle Database 10g Release 1 (10.1) or later behaves in exactly the same way as previous releases.

  6. Initialization parameters DB_BLOCK_BUFFERS and DB_BLOCK_SIZE must be set to values you have chosen for Oracle Database.

    Note:

    The total number of bytes of database buffers (that is, DB_BLOCK_BUFFERS multiplied by DB_BLOCK_SIZE) is no longer limited to 3 GB.

    Dynamic SGA and multiple block size are not supported with VLM. When VLM is enabled, the following new buffer cache parameters are not supported:

    • DB_CACHE_SIZE

    • DB_2K_CACHE_SIZE

    • DB_4K_CACHE_SIZE

    • DB_8K_CACHE_SIZE

    • DB_16K_CACHE_SIZE

    • DB_32K_CACHE_SIZE

    To select the block size for the instance, use the initialization parameter DB_BLOCK_SIZE. The buffer cache size is set by the initialization parameter DB_BLOCK_BUFFERS.

  7. Registry parameter AWE_WINDOW_MEMORY must be created and set in the appropriate key for your Oracle home. This parameter is specified in bytes and has a default value of 1 GB. AWE_WINDOW_MEMORY tells Oracle Database how much of its 2 GB (3 GB if you enabled 4 GT) address space to reserve for mapping in database buffers.

    This memory comes from the 2 GB (3 GB if you enabled 4 GT) virtual address space in Oracle Database, so its value must be less than 3 GB. Setting this parameter to a large value has the effect of using more of the address space for buffers and using less AWE memory for buffers. However, since accessing AWE buffers is somewhat slower than accessing virtual address space buffers, Oracle recommends that you tune these parameters to be as large as possible without adversely limiting database operations.

    In general, the higher AWE_WINDOW_MEMORY is set, the fewer connections and memory allocations will be possible for Oracle Database. The lower AWE_WINDOW_MEMORY is set, the lower the performance.

  8. Once this parameter is set, Oracle Database can be started and will function exactly the same as before except that more database buffers are available to the instance. In addition, disk I/O may be reduced because more Oracle Database data blocks can be cached in the System Global Area (SGA).

    Note:

    Registry parameter VLM_BUFFER_MEMORY, which enabled VLM configurations in earlier releases, is not supported in Oracle Database 10g Release 1 (10.1) or later.

VLM Instance Tuning

VLM configurations improve database performance by caching more database buffers in memory. This reduces disk I/O compared to configurations without VLM. VLM support in Oracle Database 10g Release 1 (10.1) or later has been re-written to integrate very closely with Windows. Compared to Oracle8i release 2 (8.1.6), VLM users should see better performance with the newer implementation.

Tuning for VLM is no different than tuning for configurations without VLM. It is an iterative task that begins by selecting appropriate DB_BLOCK_SIZE and DB_BLOCK_BUFFERS initialization parameters for the application being supported.

Note:

VLM configurations do not support multiple database block sizes.

AWE_WINDOW_MEMORY, a new registry parameter specific to VLM, tells Oracle Database how much of its address space to reserve for mapping in database buffers. It defaults to a value of 1 GB, which should be suitable for most installations. If DB_BLOCK_SIZE is large, however, the default AWE_WINDOW_MEMORY value of 1 GB may not be sufficient to start the database.

Increasing the value of AWE_WINDOW_MEMORY will improve performance, but it will also limit the amount of memory available for other Oracle Database threads (like foreground threads). Clients may see "out of memory" errors if this value is set too large. As a general guideline, increase the AWE_WINDOW_MEMORY registry value by 20 percent.

For example, if DB_BLOCK_SIZE is set to 8 KB, AWE_WINDOW_MEMORY is set to 1 GB, and the number of LRU latches is set to 32 (16 processor computer), then database startup fails with out of memory errors 27102 and 34. Increasing the value of AWE_WINDOW_MEMORY to 1.2 GB fixes the problem.

Having a large cache in a VLM configuration may also slow down database writer (DBWR) threads. Having more DBWR threads will distribute work required to identify and write buffers to disk and will distribute I/O loads among threads. Initialization parameter DB_WRITER_PROCESSES enables you to configure multiple database writer threads.

A large cache can also introduce contention on the LRU (least recently used) latch. On symmetric multiprocessor (SMP) systems, Oracle Database sets the number of LRU latches to a value equal to one half the number of processors on the system. You can reduce contention on such configurations by increasing the number of LRU latches to twice (or four times) the number of processors on the system.

See Also:

Oracle Database Performance Tuning Guide for more information on instance tuning

Windows 4 GB RAM Tuning (4GT)

The following 32-Bit Windows operating systems include a feature called 4 GB RAM Tuning (4GT):

  • Windows Server 2003 R2

  • Windows Server 2003

  • Windows 2000 Advanced Server

  • Windows 2000 Datacenter Server

  • Windows Vista

Note:

4GT is not supported on Windows x64.

This feature allows memory-intensive applications running on Oracle Database Enterprise Edition to access up to 3 GB of memory, as opposed to the standard 2 GB in previous operating system versions. 4GT provides a tremendous benefit: 50 percent more memory is available for database use, increasing SGA sizes or connection counts.

Large User Populations

Several features allow Oracle Database to support an increasingly large number of database connections on Windows:

  • Oracle Database Shared Server Process, which limits the number of threads needed in the Oracle Database process, supports over 10,000 simultaneous connections to a single database instance.

  • Oracle Net multiplexing and connection pooling features allow a large configuration to connect more users to a single database instance.

  • Oracle RAC raises connection counts dramatically by allowing multiple server computers to access the same database files, increasing the number of user connections by tens of thousands, as well as increasing throughput.

    Note:

    Oracle RAC is not supported on Windows XP and Windows Vista.

Oracle Database Integration with Windows

Oracle Database is increasingly integrated with Windows, easing maintenance and improving enterprise-level deployment in security, directory, and transaction services. Integration features in Oracle Database include:

Oracle PKI Integration with Windows

Oracle Advanced Security includes Oracle PKI (public key infrastructure) integration for authentication and single sign-on. You can integrate Oracle-based applications with the PKI authentication and encryption framework, using Oracle Wallet Manager.

Oracle Services for Microsoft Transaction Server

Microsoft Transaction Server (MTS) is used in the middle tier as an application server for COM/COM+ objects and transactions in distributed environments. In Windows 2000 and Windows XP it is part of COM+. Oracle Services for Microsoft Transaction Server allows Oracle Database to be used as a resource manager in Microsoft Transaction Server-coordinated transactions, providing strong integration between Oracle solutions and Microsoft Transaction Server. Oracle Services for Microsoft Transaction Server can operate with Oracle Database running on any operating system.

Oracle Database takes advantage of a native implementation and also stores recovery information in Oracle Database itself. Oracle Services for Microsoft Transaction Server allows development in all industry-wide data access interfaces, including Oracle Objects for OLE (OO4O), Oracle Call Interface (OCI), ActiveX Data Objects (ADO), OLE DB, and Open Database Connectivity (ODBC). The Oracle APIs, OO4O and OCI, offer greatest efficiency.

Note:

  • Microsoft Transaction Server is a part of COM+ on Windows Vista. However, Oracle Services on Microsoft Transaction Server are not supported on Windows Vista.

  • Oracle Objects for OLE (OO4O) is not supported on Oracle Database 11g Release 1 (11.1) for 64-bit Windows.

Oracle Fail Safe Integration with Windows

Oracle Fail Safe ensures that Oracle Database (and also other Oracle and third-party applications) can be configured and managed for high availability on Windows clusters. An instance runs on only one node at a time.

A cluster is a group of independent computing systems that operates as a single virtual system, eliminating individual host systems as points of failure. Oracle Fail Safe works with Microsoft Cluster Server to ensure that if a failure occurs on one cluster system, then workloads running on that system fail over quickly and automatically to a surviving system. Oracle Database combined with Oracle Fail Safe on a Windows cluster ensures protection from both hardware and software failures.

For well-configured solutions, Oracle Fail Safe ensures a surviving system to be operational in less than a minute, even for heavily-used databases.

Note:

On Windows 32-Bit systems, Windows XP and Windows Vista do not support the clustering technology found in Microsoft Cluster Server. Therefore, Oracle Fail Safe Server, which integrates with Microsoft Cluster Server, is not supported on Windows XP and Windows Vista. Oracle Fail Safe Manager Console is supported.

On Windows x64, Oracle Fail Safe Manager is not supported.

See Also:

Your Oracle Fail Safe documentation set, available on separate media in the Oracle Database media pack

Oracle RAC Integration with Windows

Oracle RAC is integrated with Microsoft Cluster Server clusters deployed on all Windows operating systems that support clustering. This enhances high availability features of Oracle RAC by offering:

  • Optional automatic restarts of a failed instance or listener in a cluster

  • Detection and resolution of instance hangs

  • Elimination of connect-time failover TCP/IP timeout delays for new connection requests

  • Use of user-written scripts after database state (online/offline) changes

Other Sources of Information

See the following sources for additional information: