Oracle9i Database Platform Guide
Release 2 (9.2) for Windows
Part No. B10163-01
This chapter describes how Oracle9i architecture takes advantage of some of the more advanced services in Windows operating systems.
This chapter contains these topics:
Oracle9i 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.
Oracle9i operates the same way on Windows as it does on other platforms. The architecture offers several advantages on Windows, such as:
The internal process architecture of Oracle9i 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 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.
Oracle9i database is not a typical Windows process. On Windows, an Oracle 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 startup.
When running multiple Oracle 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. Oracle architecture on Windows is illustrated in Figure 1-1. Examples of optional and required threads on Windows are listed in Table 1-1.
Figure 1-1 Oracle architecture on Windows. The background processes read and write from the various datafiles, depending on your configuration.
Table 1-1 Required and Optional Oracle Threads
||checkpoint process (or thread on Windows) that runs by default on Windows||Optional|
||archive process (or thread on Windows)||Optional|
||distributed recovery background process||Optional|
Note:You can view running background processes by issuing the following query:
SQL> select * from v$bgprocess where paddr <> '00' ;
Oracle9i 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 process. (Oracle Corporation recommends you use this tool only under the guidance of Oracle Support Services.)
Oracle9i 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 on Windows and for those cases where performance needs to be maximized.
All Oracle9i file I/O routines support 64-bit file offsets, meaning there are no 2 GB or 4 GB file size limitations when it comes to data, log, or control files, as there are on some other platforms. In fact, the limitations that are in place are generic Oracle limitations across all platforms. These limits include 4 million database blocks for each file, 16KB maximum block size, and 64K files for each database. If these values are multiplied, then maximum file size for a database file on Windows is 64 GB, and maximum total database size supported (with 16KB database blocks) is 4 petabytes.
Windows supports raw files, similar to UNIX. Using raw files for database or log files can have a slight performance gain. 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. However, standard Windows commands do not support manipulating or backing up raw files. As a result, raw files are generally used only by very high-end installations and by Oracle Real Application Clusters, where they are required.
To Oracle9i, raw files are no different from other Oracle9i database files. They are treated in the same way by Oracle as any other file and can be backed up and restored through Recovery Manager or OCOPY.
Features in Oracle9i and in the Windows operating system work together to help increase scalability, throughput, and database capacity. These features include:
Oracle9i release 2 (9.2) for Windows supports Very Large Memory (VLM) configurations in Windows 2000 and Windows XP, which allows Oracle9i release 2 (9.2) to access more than the 4 gigabyte (GB) of RAM traditionally available to Windows applications.
Note:This feature is not supported on Windows NT, and it is available on Windows 2000 and Windows XP only with Intel Pentium II and Pentium III Xeon 32-bit processors.
Note:Oracle9i release 2 (184.108.40.206) for 64-bit Windows does not support VLM. See "Oracle9i Architecture on 64-Bit Windows".
Specifically, Oracle9i release 2 (9.2) uses Address Windowing Extensions (AWE) built into Windows 2000 and Windows XP to access more than 4 GB of RAM.
The requirements for taking advantage of this support are:
The computer on which Oracle9i release 2 (9.2) is installed must have more than 4 GB of memory.
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 Q268363 for instructions on modifying
boot.ini to enable PAE.
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.
The user account under which Oracle9i release 2 (9.2) runs (typically the LocalSystem account), must have the "Lock memory pages" Windows 2000 and Windows XP privilege.
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 Oracle9i release 2 (9.2) behaves in exactly the same way as previous releases.
DB_BLOCK_SIZE must be set to values you have chosen for Oracle9i database.
Note:The total number of bytes of database buffers (that is,
Dynamic SGA and multiple block size are not supported with VLM. When VLM is enabled, the following new buffer cache parameters are not supported:
To select the block size for the instance, use the initialization 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 Oracle9i release 2 (9.2) how much of its 3 GB address space to reserve for mapping in database buffers.
This memory comes from the 3 GB virtual address space in Oracle9i release 2 (9.2), 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 Corporation 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 Oracle9i release 2 (9.2). The lower
AWE_WINDOW_MEMORY is set, the lower the performance.
Once this parameter is set, Oracle9i release 2 (9.2) 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 data blocks can be cached in the System Global Area (SGA).
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 Oracle9i release 2 (9.2) has been re-written to integrate very closely with Oracle9i database. 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_BUFFERS initialization parameters for the application being supported.
Note:Oracle9i release 2 (9.2) VLM configurations do not support multiple database block sizes.
AWE_WINDOW_MEMORY, a new registry parameter specific to VLM, tells Oracle9i 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 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, Oracle9i 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:Oracle9i Database Performance Tuning Guide and Reference for more information on instance tuning
The following Windows operating systems include a feature called 4 GB RAM Tuning (4GT):
Windows Server 2003
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Windows NT 4.0 Enterprise Edition
This feature allows memory-intensive applications running on Oracle9i 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.
Note:Neither Windows XP 64-Bit Edition Version 2003 nor the 64-bit version of Windows Server 2003 support 4 GB RAM Tuning, so it is not available in Oracle9i release 2 (220.127.116.11) for 64-bit Windows. See "Oracle9i Architecture on 64-Bit Windows".
Several features allow Oracle9i to support an increasingly large number of database connections on Windows:
Oracle 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 Real Application Clusters 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 Real Application Clusters is not supported on Windows XP.
Oracle is increasingly integrated with Windows, easing maintenance and improving enterprise-level deployment in security, directory, and transaction services. Integration features in Oracle9i include:
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 the following tools:
Oracle Enterprise Login Assistant creates the obfuscated decrypted Oracle Wallet, used by Oracle applications for Secure Sockets Layer (SSL) encryption. The Oracle Wallet is then stored on the file system or Oracle Internet Directory.
Oracle customers with large user populations often require enterprise-level security and schema management. Oracle security and administration are integrated with Windows through Active Directory, Microsoft's directory service.
Oracle9i provides native authentication and single sign-on through Windows authentication mechanisms. Native authentication uses Kerberos security protocols on Windows and allows the operating system to perform user identification for Oracle databases. With native authentication enabled, users can access Oracle applications simply by logging into Windows. Single sign-on eliminates need for multiple security credentials and simplifies administration.
Oracle native authentication also supports Oracle9i enterprise users and roles. Traditionally, administrators must create a database user on every database for each Windows user. This often equates to thousands of different database users. Oracle enterprise user mappings allow many Windows users to access a database as a single global database user. These enterprise user mappings are stored in Active Directory. For example, entire organizational units in Active Directory can be mapped to one database user.
Oracle also stores enterprise role mappings in Active Directory. With such roles, a database privilege can be managed at the domain level through directories. This is accomplished by assigning Windows users and groups to Oracle enterprise roles registered in Active Directory. Enterprise users and roles reduce administrative overhead while increasing scalability of database solutions.
Oracle also uses Active Directory to improve management of database connectivity information. Traditionally, users reference databases with Oracle Net-style names resolved through the tnsnames.ora configuration file. This file has to be administered on each client computer.
Oracle Net Naming with Active Directory stores and resolves names through Active Directory. By centralizing such information in a directory, Oracle Net Naming with Active Directory eliminates administrative overhead and relieves users from configuring their individual client computers.
Various Windows tools, such as Windows Explorer and Active Directory Users and Computers, have been enhanced. Users can now connect to databases and test database connectivity from these tools.
Oracle tools have also been enhanced. Database Configuration Assistant automatically registers database objects with Active Directory. Oracle Net Manager, meanwhile, registers net service objects with the directory. These enhancements further simplify administration.
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 Oracle9i databases to be used as resource managers 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 Oracle9i databases running on any operating system.
Oracle takes advantage of a native implementation and also stores recovery information in Oracle9i 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.
Oracle Fail Safe ensures that Oracle databases (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. Oracle9i 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:Windows XP does 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. Oracle Fail Safe Manager Console is supported.
See Also:Your Oracle Fail Safe documentation set, available on separate media in the Oracle CD-ROM package
Oracle Real Application Clusters Guard integrates Oracle Real Application Clusters databases with Microsoft Cluster Server clusters deployed on all Windows operating systems that support clustering. It enhances high availability features of Oracle Real Application Clusters 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
Note:Oracle Real Application Clusters Guard is not supported on Windows XP.