Release 2 (9.2) for Windows
Part Number A95490-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Database Getting Started Release 2 (9.2) for Windows Part Number A95490-01 |
|
This chapter describes how Oracle9i architecture takes advantage of some of the more advanced services in the Windows operating system.
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:
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. Examples of optional and required threads on Windows are listed in Table 4-1.
|
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 utility 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 size. 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.
New 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. |
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:
SYSTEM 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_BUFFERS and DB_BLOCK_SIZE must be set to values you have chosen for Oracle9i database.
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 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.
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_SIZE and DB_BLOCK_BUFFER initialization parameters for the application being supported.
AWE_WINDOW_MEMORY, a new registry parameter specific to VLM, defaults to a value of 1 GB, which should be suitable for most installations. This parameter tells Oracle9i database how much of its address space to reserve for mapping in database buffers. Increasing this value 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.
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 |
Windows NT Server Enterprise and Datacenter Editions (version 4.0) include a feature called 4 GB RAM Tuning (4GT). 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. 4GT is also supported on Windows 2000 Advanced Server and Windows 2000 Datacenter Server.
New features allow Oracle9i to support an increasingly large number of database connections on Windows NT and Windows 2000:
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 customers with large user populations often require enterprise-level security and schemas management. Oracle security and administration are integrated with Windows 2000 through Active Directory, Microsoft's directory service.
Oracle9i provides native authentication and single sign-on through Windows 2000 authentication mechanisms. Native authentication uses Kerberos security protocols on Windows 2000 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 2000 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 tools in Windows 2000, 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 is used in the middle tier as an application server for COM/COM+ objects and transactions in distributed environments. ORACLEMTSRecoveryService 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. ORACLEMTSRecoveryService 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. ORACLEMTSRecoveryService 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 (included with Oracle9i Enterprise Edition) 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.
| 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 Windows NT and Windows 2000. It enhances high availability features of Oracle Real Application Clusters by offering:
See Also:
|
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|