Oracle is the leading database system on a well-known UNIX hardware platform. Oracle users and administrators are therefore familiar with the Oracle Architecture on UNIX platforms and the tools and techniques above it, and get the most out of their databases. On the contrary, the Oracle architecture on Windows is less widely understood. This article examines the key similarities and differences between the two operating systems from a DBA's point of view.
Brief introduction
After reading a few disappointing books on this, we wrote this article. The common problem with those books is trying to do too many things-telling windows and Oracle in detail. Our article assumes that the reader is familiar with the work of Oracle DBAs on UNIX platforms. So this article will analyze the key differences in Oracle on two platforms rather than teach you Oracle skills from the beginning. We don't want to use it as an exhaustive guide or as a substitute for a handbook, in fact it may encourage you to read some manuals. As a database server platform, it will only involve some UNIX and Windows-related benefits, which is the purpose of this article.
Example
This example uses the Oracle 8i on Linux, and the instance name is called Eighti. The instance name of Oracle 8i above Windows 2000 is called Atei.
Client Access to Oracle
When a client connects to Oracle, the platform for the Oracle server is typically independent of the client's application. This is actually hard to tell. ORACLE DBAs and system administrators are more concerned with operating system platforms, and they sometimes choose platforms based on requirements such as uptime and scalability. More often, they accept (or take over) a given platform and learn to derive maximum benefit from it.
About Windows 2000
It is worth mentioning that Windows 2000 is upgraded from Windows NT. There are a lot of similarities between the two operating systems, and Windows 2000 has some new features. Microsoft's upgrade path from NT4.0 is shown in the table below.
There are many similarities between the two systems:
The following sentence is familiar to people who have used Oracle: "Each operating Oracle database corresponds to an Oracle instance, and when a database is started on the database server (regardless of the type of machine), Oracle assigns a piece called system The memory area of Global area (SGA) and initiates one or more Oracle processes. The SGA and Oracle processes together are called Oracle instances. "--excerpted from ORACLE 8i Concepts [4 L Leverenz, 1999]. Dealing with background processes is the first and the most obvious difference between different operating systems.
Oracle background processes on UNIX
Any user connected to Unix can easily look at Oracle's background processes:
The last line of the Oracle process is related to a sql*plus session, and the other processes are background processes. In Oracle we can view these processes by entering the Sql*plus session:
SELECT SID, SPID, Osuser, S.program
From V$process p, v$session s WHERE p.addr=s.paddr;
Each background process has a row, and one line of information is associated with the Sql*plus session, and the SPID corresponds to the corresponding UNIX process number.
Oracle background processes on WINDOWS2000
Back on windows, it is difficult to see the background process from the operating system. You may see a running application from Task Manager (Task Manager View: Right-click on the taskbar to select Task Manager). ORAC on the server
Le can be usable, and the running application is not visible. The process table does show a process called ORACLE.EXE,
Check alert log to show that all background processes for Oracle are started:
Pmon started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
Smon started with pid=6
Reco started with pid=7
To see the actual background process, you need to run additional software, such as a process viewer. The software can be used from windows
From the CD (Windows NT can be obtained from the resource bundle).
On Windows 2000, ORACLE instances are implemented as a single Windows 2000 process (ORACLE.EXE). This process includes the threads for each task that the instance needs to implement.
So a thread corresponds to each Oracle background process. ORACLE. The EXE process runs as a service and can be viewed from the services of the Control Panel Oracleservicesid. Other services can also be controlled in this way.
This allows Oracle to continue running without the user logging on to the server. For all processes sharing Master processor resources, Oracle is able to achieve high speed, low load context switching.
displaying processes in Oracle under UNIX can also be achieved by entering simple SQL statements. In order to display the PID column, the SQL statement made some minor changes. Be aware of the values reported in the PID match warning log.
Each background process has a row, and one row of information is associated with the Sql*plus session. The program name does not indicate the name of the background process, as in Unix, these names can be obtained by connecting to the v$bgprocess.
SELECT s.sid Sid, P.spid THREADID, P.program processname, bg.name name
Submitting SQL Commands ALTER SYSTEM DISCONNECT session can disconnect sessions. There are times when the session needs to be disconnected at the operating system level, on Unix, through the KILL command, and the SQL session in the previous example can be disconnected by entering UNIX commands:
Kill-9 19168
You can disconnect a session with Orakill on Windows 2000. Orakill is a specific command for ORACLE on the Windows platform, and is installed by default under $oracle_home\bin. Enter Orakill at the command line to see its usage. The Sql*plus session in the previous example can be disconnected by entering the following command:
Orakill Atei 1200
Kill of thread ID 1200 in instance Atei successfully signaled.
In Windows 2000, if a disconnected session is marked "Marked for kill" but has not been deleted, Orakill terminates it. Remember that killing a background process is not always a good idea, especially on windows, which can cause a process to crash or even render the database unusable.
Windows 2000 Registry
As with other applications in Windows 2000, most of Oracle's settings are in the registry. You should see what's underneath HKEY_LOCAL_MACHINE Oftware\oracle. Some of these parameters are discussed in detail later. The parameters associated with Oracle services are stored in the same location as other services:
Two of the most important variables in UNIX are Oracle_home and oracle_sid. Once these variables are set, the application can be run in parallel to the local database. $oracle_home/bin are usually included in the $PATH
In order to eliminate the hassle of entering the full path when using Oracle tools such as: Sqlplus.
In Windows 2000, you can open the command line setting ORACLE_SID variable and then join to the local database. Other values can be obtained from the registry.
Multiple ORACLE Homes
Windows 2000 fully supports multiple Oracle home. Previously, this was a major issue on Windows NT and was not supported until ORACLE8.0.4. The initial support for this was poor. Oracle Home Selector, a new application tool for oracle8i, changes the environment path to make the chosen Oracle home path the primary home. Simply change the system path and place the Oracle-selected Bin directory in the boot path.
Each bin directory has a Oracle.key file that indicates where the Oracle program can find oracle_home and other environment variables in the registry. If there is only one database on the server, Oracle_sid is usually set in the registry. However, do not set Oracle_home, which is not needed for ORACLE products and may cause problems.
File system
Multiple ORACLE home support allows Unix OFA standards to be implemented on Windows. This greatly simplifies the transition from UNIX. The top level of the OFA tree has a different name, but the primary subdirectory and file name are the same in both operating systems.
Unix
Nt
Oracle_base
/oracle/app/oracle
D:\Oracle
Oracle_home
/oracle/app/oracle/product/8.1.7
D:\Oracle\Ora817
Admin Directories
/oracle/app/oracle/admin
D:\Oracle\Admin
Database files
/db01/oradata/sid
D:\Oracle\Oradata ID
/db02/oradata/sid
F:\Oracle\Oradata ID
/db03/oradata/sid
G:\Oracle\Oradata ID
Service Manager
Starting with Oracle 8i, the name of the service Manager is consistent on different platforms, called SVRMGRL. Previously in
The name of Oracle's executable file on Windows NT changes with version changes, which is annoying for people working on multiple platforms, especially when using commands (IMP, EXP, etc.).
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
