The Oracle DBA's Guide to NT

ORACLE ARCHITECTURE ON NT

• An area of memory available to all Oracle sessions, known as the system global area (SGA). This area of memory includes recently accessed data blocks (the buffer cache), SQL and PL/SQL objects (the library cache), and transaction information (the redo log buffer). The SGA may also contain session information.
• Several tasks that perform dedicated database activities, including the database writer (DBWR), redo log writer (LGWR), system monitor (SMON), process monitor (PMON), and log archiver (ARCH). Other tasks may be configured if required to support Oracle options such as parallel query, distributed database, or multithreaded servers. We will refer to these tasks as background tasks (although they are also often referred to as background processes ).
• Oracle data files that contain the tables, indexes, and other segments that form the Oracle instance
• Redo logs, which record critical transaction information required for roll-forward in the event of instance failure
• A separate task created to perform database operations on behalf of each Oracle session, which I'll refer to as a dedicated server. If the multithreaded server option is implemented, many sessions can be supported by a smaller number of shared servers.
• A SQL*Net listener task that establishes connections from external systems.
• Database and redo log files are generally implemented using the operating system's native file system or raw disk partitions, and port-specific  differences at the file level are relatively minor. However, the memory and process structure of an Oracle instance will vary significantly depending on how the operating system implements process and memory management.
• In Unix, each Oracle task is implemented as a Unix process. Accordingly, a process is created for each Oracle background task and for each (dedicated or shared) server task. The SGA exists within Unix shared memory, which any of the background or server tasks can access. Figure 1 illustrates the Oracle/Unix architecture.

MEMORY

STARTUP AND SHUTDOWN

• OracleServiceSID. This service must be defined for each Oracle instance on the NT server. SID represents the instance identifier; in other words, OracleServiceABC1 represents the instance ABC1. Starting this service creates the Oracle process.
• OracleStartSID. Starting this service performs an automatic startup for the instance in question--equivalent to issuing a startup command from Server Manager.
• OracleTNSListener. This service implements the SQL*Net listener.

net start OracleServiceGDB1
net start OracleStartGDB1
net start OracleTNSListener80

Using the Oracle Database Instance Manager ORADIM80.EXE
You can use this program to control all aspects of Oracle services. For example, to shutdown the database use the command:
        oradim80.exe -shutdown -sid ORCL -usrpwd passwd -shuttype (srvc,inst) -shutmode I
where shutmode can be a-abort; i-immediate or n-normal.
 

INSTALLATION

    When you've created your basic database using the database assistant, you can use Server Manager or other tools to create additional tablespaces or data files and edit the initSID.ora file to add or change configuration parameters.
    Finally, you would select the new instance by setting your Oracle_ SID and would use Server Manager to create the database, run the catalog scripts, and create tablespaces.

MULTIPLE SOFTWARE VERSIONS

PERFORMANCE MONITORING

• The application list tracks open windows and applications that are currently running.
• The process list shows all active processes together with configuration information such as CPU usage, physical and virtual memory usage, and priority. Figure 5 shows a Task Manager process list sorted by virtual memory. You can see that the Oracle executable is consuming the most virtual memory. Its virtual memory size of 19.4MB includes the SGA and memory for all server threads. You can also see that the process contains 15 threads, which indicates the number of sessions connected to the database. In this case, the 15 threads correspond to six background threads, seven dedicated server threads, and two overhead threads.
• The final page of the task manager shows detailed memory and CPU usage. It provides a quick overview of CPU and memory consumption

    The Windows NT Performance Monitor displays a range of performance metrics, including overall CPU, memory, network, and disk metrics, not only at a summary level but also for individual threads and processes. The tool can record metrics to a log file for later playback and can report in both graphical and report formats. From an Oracle DBA's perspective, the best thing about the NT Performance Monitor is that it can also display or record Oracle performance metrics--provided you install the Oracle performance manager option. Figure 6 shows an example of the performance monitor reporting on both Oracle and NT metrics.

    While the integration of Oracle and NT performance metrics provides an excellent means of correlating database and operating system performance metrics, Oracle's selection of metrics is a little disappointing. For example, there is no metric that shows the number of logical reads per second or the rate of SQL statement execution. In theory, you could hand-tailor such metrics by amending the %oracle_home/dbs/perf80.ora file, which contains the SQL statements that define the metrics, but most users will prefer to employ third-party monitoring tools.

There are more important tools under Control Panel, theyr are System and Networking.
System lets you:

• Prevent a performance boost for any foreground application that may also be running
• View and Modify the size of the paging file(s)
• Examine the values of, and set, System and user environment variables

• Choose "Maximize Throughput for Network Applications" for the Server service
• Move the most commonly used protocols, such as TCP/IP, to the top of the Binding list
• Remove any protocols that were installed but are not being used.

MONITORING THREADS

LISTING 1. CPU usage query.
column program format a20
column username format a12
select p.spid thread, s.username,
    decode(nvl(p.background,0),1,bg.description,
         s.program ) program,
    ss.value/100 CPU,physical_reads disk_io
from v$process p,
    v$session s,
    v$sesstat ss,
    v$sess_io si,
    v$bgprocess bg
where s.paddr=p.addr
  and ss.sid=s.sid
  and ss.statistic#=12
  and si.sid=s.sid
  and bg.paddr(+)=p.addr
order by ss.value desc;

    The first two threads in the Oracle executable are the main thread and the dispatcher thread, which are not associated with any background or server process. The next five threads at least correspond to background tasks. The number of background tasks can be greater if the database is in archivelog mode, has a dedicated checkpoint process, or has implemented shared servers or parallel query.
    Although it's possible to display individual thread CPU and other resource usage in the NT performance monitor, mapping the thread numbers shown in performance monitor to thread IDs recorded in v$process is complex and unreliable because the mapping of thread IDs to thread numbers can change as threads are created and destroyed. If you need to monitor the performance of individual threads, you could try the Oracle Top Sessions monitor, which is available as an add-on to Oracle Enterprise manager, or use a third-party tool. If you install the Perl utility and the Oracle DBI interface (more on Perl later), you can use dbtop.pl script (available at  werple.net.au/~gharriso ) to monitor CPU and IO usage on a thread-by-thread basis.
 

PERFORMANCE TUNING

• Tuning SQL and the application design
• Ensuring suitably sized hardware--particularly that memory, CPU, network, and disk resources are adequate for the demands of the application
• Spreading data files evenly across a sufficient number of disks to eliminate disk bottlenecks or excessive queuing
• Separating redo logs from data files and the archive log destination, and possibly alternating redo logs across multiple disks
• Adequately sizing Oracle internal resources such as the SGA, rollback segments, sort areas, and temporary tablespace.

• Windows NT supports asynchronous I/O; configuring multiple db writers is not required.
• You can create raw partitions for Windows NT for highly I/O-intensive applications. The pros and cons of NT raw partitions are the same as those for Unix raw partitions. If you're not using raw partitions, you will have the choice of either FAT or NTFS ones (see sidebar, "Which File System To Use?"). You may get some small performance improvement using NTFS partitions, but more important, only NTFS partitions can properly implement NT security. If you implement data files on FAT partitions, they can be viewed by anyone with access to the NT server. On NTFS, you can restrict access to DBA accounts only

General settings
NT provides settings that allow the O/S to "tune itself" to favor particular types of applications and usage. Since NT supports a wide range of network services (such as file serving, web-serving, application services, etc.), these settings allow the administrator to instruct the operating system to allocate resources to optimize their usage for a particular type of service. For function as an ORACLE database server, the following settings should be verified or enabled:

1) Optimize for network throughput. This setting instructs NT to allocate resources such that they are more available and useable to application processes that execute locally on the server. This setting defaults to "Optimize for file sharing", and modifying this setting will typically generate a performance improvement of 5-10% in the ORACLE instance. Note that this setting requires a reboot before it takes effect. This setting can be found in the following location:
START -> Settings -> Control Panel -> Network -> Services -> Server -> Properties -> Maximize throughput for network applications.

2) Minimize foreground boost. This setting allows NT Servers that perform additional duties as user workstations to allocate more resources to interactive sessions that are logged into the console, and defaults to 50%. Assuming this box is a dedicated database server, then this setting should be set such that interactive logins are not given priorities higher than the ORACLE services. Due to NT's architecture, certain administrative tasks may require console login, and it is undesirable for the database end-users to experience a performance degradation each time an interactive login occurs. This setting essentially minimizes a 5-10% degradation during interactive login sessions. Note that this setting requires a reboot before it takes effect. This setting can be found in the following location:
START -> Settings -> Control Panel -> System -> Performance -> Foreground boost = none.

3) DiskPerf. This setting causes disk performance objects and counters to be loaded at boot time. Without this setting toggled on, examining disk performance with NT Performance Monitor will result in all disk statistics being reported as zero. This setting incurs approximately a 5-10% performance overhead, but the information made available by enabling this setting will allow tuning analysis that it is otherwise not possible. If the disk performance information is used for bottleneck resolution, then having the information available to perform the analysis more than offsets the resulting performance loss, in the author's opinion. Note that this setting requires a reboot before it takes effect. Enable this setting from the command line by typing the following command:
diskperf -y (enables the objects and counters for logical and physical disks) or
diskperf -ye (enables the objects and counters for logical and physical disks plus individual disk drives in a stripped array)

Identifying Operating System Bottlenecks
As stated previously, there's essentially only three areas of the operating system to check for performance bottlenecks: CPU, memory, and disk. NT Performance Monitor provides easy access the objects and counters storing the necessary information. Note that updating the GUI interface provided by PM is a fairly expensive process, although polling the object and counter information itself is reasonably inexpensive. For this reason, adopt one of the two following practices:

1) Run NT Performance Monitor from a remote workstation rather than at the console of the database server. PM can easily access performance information on a remote server, so remove the graphical workload from the database server to prevent the reported values from being over-inflated by the expensive graphical updates.

2) Install the DATALOG.EXE service on the database server, and control the service using the MONITOR.EXE command. The DATALOG.EXE (included in the NT Resource Kit) is the service-version of PM without the graphical components. It appears as "Monitor service" on the Control Panel-Services applet, it's memory and processor footprint are fairly light, and it accepts a performance monitor PMW file as it's data collection configuration information. The configuration information includes the objects and counters to poll, the polling interval, and the PM logfile in which to record the performance data. This logfile of information can then be analyzed offline. Performance data regularly collected with this method also proves useful for constructing usage growth profiles to anticipate future requirements.
The following approach is organized in order of resources easiest to analyze and fix addressed first, and will provide effective results. Check CPU first, since that resource is the easiest to monitor, and typically will be the least costly to rectify. If CPU is not the bottleneck, then examine memory. Although a bit more complicated to analyze, a memory shortage is still reasonably inexpensive to fix. Memory should be examined before disk because a memory shortage will inflate the volume of disk access. If memory is not the bottleneck, then examine disk. If none of these resources appear to be the bottleneck, then instance level initialization parameters should be carefully examined, with assistance from ORACLE support if needed.

1) Check CPU utilization.
Counter: % Total Processor Time
Scrutinize average and maximum utilization. When the maximum utilitization reaches 100%, the CPU's are the bottleneck. If the CPU's consisently reach a maximum utilization of 100%, then perform additional analysis to determine what percentage of the time they are pegged at 100%. If they reach 100% only 1% of the time, but are below the 100% mark 99% of the time, then they are the bottleneck only 1% of the time. If CPU's are at or near 100% any portion of the time, then the DBA should plan ahead and budget the purchase of additional CPU resources before they are actually needed. If the CPU's never reach a max utilization of 100%, CPU is not the current bottleneck. Options for fixing a CPU bottleneck include:
- Add more CPU's
- Replace existing CPU's with processors that are faster and have larger processor caches.
Note that replacing 4 - 200Mhz Pentium Pro CPU's with 4 - 400Mhz Pentium Xeon processors is likely to result in greater overall improvement than adding 4 additional 200Mhz Pentium Pro processors, given NT's scaleability characteristics.

2) Check memory.
Counter: Pages/sec
The simplest measurement of memory on NT is the rate of paging. Average and maximum paging should be examined, with additional analysis such as calculating the percentile divisions for particular time windows if maximum paging is excessive. Hit ratios for SGA memory structures (such as buffer cache) may be within the target range that should yield adequate performance (typically 80-95%, depending on a particular organization's requirements and expectations), but checking only SGA hit ratios may be misleading. NT virtual memory works such that the total memory available to an application (up to the maximum O/S limit) is the combination of physical memory and paged memory (ie. memory contents temporarily written to disk). Buffer cache hit ratio could read 95%, but if physical memory is being paged hundreds of times per second, a severe performance degradation will be experienced. Typically, the best balance on NT is 40-45% of the physical memory available on the server allocated to the SGA. A rate of memory paging greater than approximately 5 pages/second will result in exponential performance degradation. If SGA hit ratios are low, then increase the memory allocated to the necessary cache. If SGA hit ratios are high but the O/S is paging more than the suggested minimum, then add more physical memory to the server. Ideally, the DBA should plan ahead and budget the purchase of additional memory before hit ratios and paging becomes a significant bottleneck. If the SGA hit ratios are within the target range and O/S paging is minimal, then memory is not the bottleneck. Note that it is possible to allocate too much memory to the SGA: in this scenario, the SGA hit ratios will be excellent, but paging will occur at a rate than more than offsets the better hit ratios, thus making overall performance slower than it would be with lower SGA hit ratios. The objective for memory should be balancing between SGA hit ratios and O/S paging. Options for fixing a memory shortage include:
- Adjusting SGA memory allocations to balance the ORACLE hit ratios and O/S paging.
- Add physical memory to the server.

3) Check disk.
Counters (for each logical disk): Disk transfers/sec and Avg Disk sec/transfer
Examine the workload imposed upon the disks used by the ORACLE instance. Logical disks, whether single physical disks or disk arrays, have a workload threshold that they can sustain without performance degradation; after that workload threshold is exceeded, read and write performance will degrade exponentially. Throughput is defined as the rate of data transfer, while workload is defined as the rate of I/O requests. In practice, the rate that data is read or written is relatively constant, given that the disk rotates at a constant speed. Because of the characteristic mechanical and rotational latencies, finding the data on disk can take as long or longer than performing the actual transfer, particularly in cases (like database systems) where the nature of disk I/O is more random than sequential. With this attribute in mind, it should be noted that workload is the most likely candidate to overload a disk's performance capacity. As the workload threshold (ie. transfers/second) of the disk or disk array is exceeded the amount of time to complete each request (seconds/transfer) will increase exponentially. Most hot-swappable SCSI disk is capable of sustaining around 60-80 transfers/second, depending upon the particular model and vendor. (Contact your hardware vendor to obtain these attributes specific to your particular disk drive models.) With this information available for each disk, the approximate workload threshold can be calculated for disk arrays visible to the O/S as single logical disks. (Please see the article on RAID in this section for the equations to approximate this workload threshold.) For instance, if we have a disk array that has a workload threshold of 180 transfers/second, the seconds/transfer should be in the millisecond range when the actual workload is below this limit. When this workload threshold becomes drastically exceeded, the seconds/transfer will increase into the tens or even hundreds of milliseconds. Unfortunately, I/O-bound situations are typically the most difficult and costly to fix. Options include:
- Balancing the disk I/O over multiple disks or disk arrays/controllers using information obtained from the ORACLE instance's BSTAT/ESTAT reports (please see the article on instance tuning for more information).
- Add physical disks individually or to arrays to increase the workload threshold.
- Add more independent disk arrays and controllers to the database server.
- Change the selected RAID technology (RAID5 to RAID1 or RAID10, non-RAID to RAID0, etc.).
- Replace disks or arrays with faster disk and/or array controllers.
- If SGA hit ratios are below ideal, add a significant volume of memory to reduce disk usage. Note that the higher the SGA hit ratios already are, the less effective this approach will be.
 

Isolation from other application services and environmental variables
One of the most effective techniques for improving the availability of a given ORACLE on NT instance is to isolate the database service from other application services. A production ORACLE instance with requirements to support more than a handful of concurrent users and/or with stringent availability requirements should be run on a dedicated database server. Below are details of specific steps that can be implemented.

1) Do not run the ORACLE instance on a primary or backup domain controller. Services on the PDC or BDC can impact the ORACLE instance, as well as the ORACLE instance having a undesired impact on the PDC.

2) Limit file service access to the database server. Only the DBA's and system or network administrators (plus perhaps a few application developers) need access to the file system. End users should not be able to store documents, spreadsheets, etc., on the file system of the database server. File serving and sharing on the database server absorbs computing resources as well as giving end users an opportunity to accidentally damage data files, executables, scripts, etc., used by the database instance, unless the file system security is tightly managed. In this case, the best course of action is avoidance. There may be lots of space available on the database server, but the assumption should be made that the database will need most or all of that space at some future point in time.

3) Limit print services on the database server. There will likely be very few cases where print services from database server are actually needed. Eliminate this overhead and any associated stability risks by refraining from using the print services through the database server.

4) Limit console login authority. Only the DBA's and system administrators need login authority to the database server. Console login privileges provide the ability to accidentally start or stop a variety of services that can impact the ORACLE instance, as well as the ability to perform a shutdown or kill operating system processes. All of these capabilities can be secured, but again the best policy is avoidance. If a well-meaning user can't accidentally break something, then he or she won't.

5) Secured physical location. The database server should be in a location that is inaccessible to everyone except the administration personnel. Ideally, this physical location should have a sufficient UPS in the event of power failure, and a fire containment system. The database server should not be physically located such that an end-user could accidentally trip over the power cord or network cabling while walking past the server.

6) One ORACLE instance and version per box. Since multiple application services compete for computing resources, only one database instance should be run per box. A database engine will attempt to use all available CPU, memory, and disk workload resources when necessary. Eliminate this competition and any instability that it generates by running only a single instance on each box, especially if these are production instances. Ideally, there should be at least two seperate database servers: one for production, and one for development. This seperation prevents development mishaps, upgrades, etc., from impacting a production instance. In some cases, a quality assurance instance is also justifiable. A good rule of thumb is to keep the development server at about half of the throughput capacity of the production server. In this way, potential performance problems are more likely to be noticed before the application goes into production.
ORACLE8 now provides the capability to have multiple versions installed on the same box through the use of multiple ORACLE_HOMES. This feature can be useful for upgrade activity, but should not be taken as an encouragement to run multiple instances (of the same or a different version) on the same box. The inability to have multiple ORACLE7 versions safely installed on the same NT box constraints the ability to apply a patch to a development instance for testing without automatically applying that same patch to all other instances on the same box. Seperation of instances not only opens up better maintenance windows, it also removes any instabilities resulting from contention and competition of instances.

7) Limit non-ORACLE software, applications, and processes. Due to the nature of Microsoft's Component Object Model, it's shared components, and the object resolution provided by the registry, it is entirely possible to install a non-ORACLE software component that damages an ORACLE-related software component or registry entry. A good rule of thumb is to assume that different applications will not run on the same box until you have explicitly proven that assumption to be false. Whether the non-ORACLE application is a commercial product or a custom creation, it's peaceful co-existence should at least be tested with a non-production instance before installing on a production instance. Ideally, this application or component should be run on a server seperate from the ORACLE database, even if it connects to and does work with the ORACLE instance. SQL*Net/NET8 provides the transport layer that makes the physical location of the ORACLE instance completely transparent to any application, so there is absolutely no reason that a server-side application that interacts with an ORACLE instance has to be installed and run on the same box, regardless of whether it is a middle-tier component, a web-server based component, etc.

8) Do not run a multi-server backup solution from the database server. Although this temptation is appealing because the database server will attain higher throughput on backups with the backup solution physically connected to and run from the database server, it can cause instabilities through competition for resources, and it generally severely limits the window of opportunity for server or database maintenance. Essentially, offline corrections and administrative work cannot be done during the day because of user workload, and cannot be done at night because the database server and other servers are being backed up by the database server. This is especially true of production instances, and can also easily become true of development instances. Avoid this particular temptation, unless the backup apparatus is dedicated only to the database server.
Isolation from other application services and environmental variables
One of the most effective techniques for improving the availability of a given ORACLE on NT instance is to isolate the database service from other application services. A production ORACLE instance with requirements to support more than a handful of concurrent users and/or with stringent availability requirements should be run on a dedicated database server. Below are details of specific steps that can be implemented.
 
 

WINDOWS REGISTRY

Under the HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE key. Some entries you might want to change are:
 

Registry Key	Value	Comments
ORA_%SID%_PWFILE %ORACLE_HOME%\DATABASE		Change location of PASSWORD file for Connect Internal
ORA_%SID%_SHUTDOWN	TRUE or FALSE	TRUE cause shutdown immediate when service terminates
ORA_%SID%_SHUTDOWN_TIMEOUT		Number Seconds to wait for timeout -numbers < 30 are ignored
ORACLE_SID	SID	Default SID
SQLPATH %ORACLE_HOME%\SQLPLUS		Directory to search for SQL files

There are a few more under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Oracle80\Performance\Oracle%HOME%80
 

SECURITY

• · tighten security for the "starter database", and
• · provide password-less connections via the Identified Externally Option.

1. Change the SYS and SYSTEM Password
2. Change the INTERNAL or DBA Password
3. Protect Oracle REGESTRY ENTRIES from view/modification
4. Protect STRTSID.CMD from viewing
5. Protect ORACLE EXECUTABLES from spoofing or deletion
6. Protect ORACLE datafiles, redo logs, control files from deletion or unauthorized capture
7. Protect EXPORTS and BACKUPS deletion or unauthorized capture

• Connecting without a password as a 'normal' user
• Connecting as SYSDBA or SYSOPER without a password
• Connecting as INTERNAL without a password
• Grant Oracle ROLES exclusively through NT groups

PERFORMING BACKUPS

SCHEDULING BACKUPS

For example, the following command runs an archive script every day at 3 p.m.:
            AT 15:00 /EVERY:m,t,w,th,f,s,su cmd /c "c:\bin\archive.bat >c:\logs\archive.log"

rem -- List jobs in scheduling queue --
AT

rem -- Remove all jobs from scheduling queue --
rem AT /DELETE /YES

rem Note: The AT command does not utilize the PATH environment variable.
rem       Use full path name to the batch file and other commands

You must start the Windows NT schedule service in order to use the at command.

Notification On Windows
Many operating systems provide an intrinsic method for sending messages via email. However, one common irritation with Windows NT is the lack of a UNIX-like "sendmail" command. Luckily, there are utilities available to add this functionality.
Here are some Windows Utilities to send mails:

http://www.aspsimply.com/mail/mailto.asp
http://www.ipass.net/~davesisk/oont_management_scripting_2.htm
http://www.bas.co.za/Exchange/mail_sender.htm
http://www.users.globalnet.co.uk/~jchap/tvde.htm
http://www.komaromi.com/dos_email/
http://home.concepts.nl/~fiber/dose.htm

In fact, one such command-line utility (MailTo.exe) is available as freeware. This particular MailTo command sends STMP mail, and can include text files as the message body or attachments, and binary files as attachments. The syntax is very simple, and since it is a command-line executable, calls to it can be included in BAT or CMD files or more advanced scripts. Below is a list of possible uses, some of which have examples in the scripting article of this section:

1) Scan the ORACLE alert log for errors using the FINDSTR command, and, if any errors are found, email them to a list of email addresses. A job such as this can be scheduled to execute every 60 minutes, for instance.
findstr /N "ORA- incomplete" C:\oracle\admin\DIE\bdump\dieALRT.LOG


2) Check services to make sure they are started, and, if not, send an email to operational personnel. Again, this type of job can be automated to run at short periodic intervals, such as every 15 minutes or once per hour. Consequently, the job could be constructed in a manner that attempts to restart the particular service, as well as mailing a note to an administrator.

3) Scan the spooled output from a hot backup for errors using FINDSTR, then email any errors that were found to an administrator. This functionality could be added to the job that runs the hot backup.

4) Scan the spooled output from a full export for errors using FINDSTR, and, if errors are found, send an email containing the error listing to a DBA. This functionality could be added to the job that actually runs the full export.

5) Perform a TNSPING or even connect to a database instance. If connection is not achieved, send an email to an administrator, and perhaps even attempt to restart the database instance if the connection error indicates the instance is not available. This type of job could be scheduled to run several times per hour, if necessary.

6) Spool the output of a DIR command, or the output of the DIRUSE command, to a text file and email this output to an administrator. This type of job can be used to monitor available disk space, and could be scheduled to run each morning, once per week, etc.

CLEANING A WINDOWS MACHINE

WITH A LITTLE HELP...

Which File System To Use?

Last thoughts

Another useful utility is called BASH, which is an Unix-like shell that can be used to run shell scripts on NT ( http://sourceware.cygnus.com/cygwin/ ). BASH is distributed via the GNU for Win32 project and is able to run most shell scripts and other Unix utilities.
You can use BASH to run your existing Unix shell scripts without porting them to CMD files.

One thing to be aware of is that Windows NT has a default behavior that is different from Unix for running scripts. In Unix, if you call a HOST command on SQL*PLUS, your scripts waits for return before executing the next HOST command. With NT, your calling script will continue without waiting and this can cause problems if commands need to be executed in order. To get around this in your scripts, you can use the command-line SQLPLUS and call the programs with the following syntax:
    HOST start/wait PROGRAM.EXE
Or
    HOST start CALL PROGRAM.EXE