Background Processes in Oracle
Background Processes in Oracle
A background process is defined as any process that is listed in V$PROCESS and has a nonnull value in the pnamecolumn.
Not all background processes are mandatory for an instance. Some are mandatory and
some are optional. Mandatory background processes are DBWn, LGWR, CKPT, SMON, PMON,
and RECO. All other processes are optional, will be invoked if that particular feature is
activated.
Oracle background processes are visible as separate operating system processes in
Unix/Linux. In Windows, these run as separate threads within the same service. Any issues
related to background processes should be monitored and analyzed from the trace files
generated and the alert log.
Background processes are started automatically when the instance is started.
To findout background processes from database:
SQL> select SID,PROGRAM from v$session where TYPE='BACKGROUND';
If any one of these 6 mandatory background processes is killed/not running, the instance
will be aborted.
Medical Question
Monitoring
System Monitoring
Whenever a log switch is occurring as redolog file is becoming CURRENT to ACTIVE stage,
oracle calls DBWn and synchronizes all the dirty blocks in database buffer cache to the
respective datafiles, scattered or randomly.
Database writer (or Dirty Buffer Writer) process does multi-block writing to disk
asynchronously. One DBWn process is adequate for most systems. Multiple database writers
can be configured by initialization parameter DB_WRITER_PROCESSES, depends on the
number of CPUs allocated to the instance. To have more than one DBWn only make sense if
each DBWn has been allocated its own list of blocks to write to disk. This is done through
the initialization parameter DB_BLOCK_LRU_LATCHES. If this parameter is not set correctly,
multiple DB writers can end up contending for the same block list.
The possible multiple DBWR processes in RAC must be coordinated through the locking and
global cache processes to ensure efficient processing is accomplished.
When the dirty blocks in SGA reaches to a threshold value, oracle calls DBWn.
When the database is shutting down with some dirty blocks in the SGA, then oracle
calls DBWn.
DBWn has a time out value (3 seconds by default) and it wakes up whether there are
any dirty blocks or not.
When a server process cannot find a clean reusable buffer after scanning a threshold
number of buffers.
When a huge table wants to enter into SGA and oracle could not find enough free
space where it decides to flush out LRU blocks and which happens to be dirty blocks.
Before flushing out the dirty blocks, oracle calls DBWn.
In RAC, each RAC instance has its own LGWR process that maintains that instances thread
of redo logs.
Whenever 1MB of redolog buffer is filled (This means that there is no sense in
making the redolog buffer more than 3MB).
When DBWn signals the writing of redo records to disk. All redo records associated
with changes in the block buffers must be written to disk first (The write-ahead
protocol). While writing dirty buffers, if the DBWn process finds that some redo
information has not been written, it signals the LGWR to write the information and
waits until the control is returned.
Performance Review
Performances
Heat Pump
Vacuum Pump
Performance Management
When checkpoint occurred it will invoke the DBWn and updates the SCN block of the all
datafiles and the control file with the current SCN. This is done by LGWR. This SCN is called
checkpoint SCN.
Manual checkpoint.
If the database is crashed (power failure) and next time when we restart
the database SMON observes that last time the database was not shutdown
gracefully. Hence it requires some recovery, which is known as INSTANCE CRASH
RECOVERY. When performing the crash recovery before the database is completely
open, if it finds any transaction committed but not found in the datafiles, will now be
applied from redolog files to datafiles.
If SMON observes some uncommitted transaction which has already updated the
table in the datafile, is going to be treated as a in doubt transaction and will be rolled
back with the help of before image available inrollback segments.
In RAC environment, the SMON process of one instance can perform instance
recovery for other instances that have failed.
This process is intended for recovery in distributed databases. The distributed transaction
recovery process finds pending distributed transactions and resolves them. All in-doubt
transactions are recovered by this process in the distributed database setup. RECO will
connect to the remote database to resolve pending transactions.
The number of archiver processes that can be invoked initially is specified by the
initialization parameter LOG_ARCHIVE_MAX_PROCESSES (by default 2, max 10). The actual
number of archiver processes in use may vary based on the workload.
ARCH processes, running on primary database, select archived redo logs and send them to
standby database. Archive log files are used for media recovery (in case of a hard disk
failure and for maintaining an Oracle standby database via log shipping). Archives the
standby redo logs applied by the managed recovery process (MRP).
In RAC, the various ARCH processes can be utilized to ensure that copies of the archived
redo logs for each instance are available to the other instances in the RAC setup should they
be needed for recovery.
This is the Oracles dynamic job queue coordinator. It periodically selects jobs (from JOB$)
that need to be run, scheduled by the Oracle job queue. The coordinator process
dynamically spawns job queue slave processes (J000-J999) to run the jobs. These jobs
could be PL/SQL statements or procedures on an Oracle instance.
CQJ0 - Job queue controller process wakes up periodically and checks the job log. If a job is
due, it spawns Jnnnn processes to handle jobs.
From Oracle 11g release2, DBMS_JOB and DBMS_SCHEDULER work without setting
JOB_QUEUE_PROCESSES. Prior to11gR2 the default value is 0, and from 11gR2 the default
value is 1000.
Lock Monitor (maximum 1) LMON
Lock monitor manages global locks and resources. It handles the redistribution of instance
locks whenever instances are started or shutdown. Lock monitor also recovers instance lock
information prior to the instance recovery process. Lock monitor co-ordinates with the
Process Monitor (PMON) to recover dead processes that hold instance locks.
Lock Manager Daemon (maximum 10) LMDn
LMDn processes manage instance locks that are used to share resources between instances.
LMDn processes also handle deadlock detection and remote lock requests.
Global Cache Service (LMS)
In an Oracle Real Application Clusters environment, this process manages resources and
provides inter-instance resource control.
The RSM process is responsible for handling any SQL commands used by the broker that
need to be executed on one of the databases in the configuration.
Data Guard NetServer/NetSlave NSVn
These are responsible for making contact with the remote database and sending across any
work items to the remote database. From 1 to n of these network server processes can
exist. NSVn is created when a Data Guard broker configuration is enabled. There can be as
many NSVn processes (where n is 0- 9 and A-U) created as there are databases in the Data
Guard broker configuration.
Managed Recovery Process MRP
In Data Guard environment, this managed recovery process will apply archived redo logs to
the standby database.
Remote File Server process RFS
The remote file server process, in Data Guard environment, on the standby database
receives archived redo logs from the primary database.
Logical Standby Process LSP
The logical standby process is the coordinator process for a set of processes that
concurrently read, prepare, build, analyze, and apply completed SQL transactions from the
archived redo logs. The LSP also maintains metadata in the database. The RFS process
communicates with the logical standby process (LSP) to coordinate and record which files
arrived.
Fetch Archive Log (FAL) Server
Services requests for archive redo logs from FAL clients running on multiple standby
databases. Multiple FAL servers can be run on a primary database, one for each FAL
request.
Fetch Archive Log (FAL) Client
Pulls archived redo log files from the primary site. Initiates transfer of archived redo logs
when it detects a gap sequence.
Creates and deletes the master table at the time of export and import. Master table contains
the job state and object information. Coordinates the Data Pump job tasks performed by
Data Pump worker processes and handles client interactions. The Data Pump master
(control) process is started during job creation and coordinates all tasks performed by the
Data Pump job. It handles all client interactions and communication, establishes all job
contexts, and coordinates all worker process activities on behalf of the job. Creates the
Worker Process.
Data Pump Worker Process DWnn
It performs the actual heavy duty work of loading and unloading of data. It maintains the
information in master table.The Data Pump worker process is responsible for performing
tasks that are assigned by the Data Pump master process, such as the loading and
unloading of metadata and data.
Shadow Process
When client logs in to an Oracle Server the database creates and Oracle process to service
Data Pump API.
New Background Processes in Oracle 10g
Memory Manager (maximum 1) MMAN
MMAN dynamically adjust the sizes of the SGA components like buffer cache, large pool,
shared pool and java pool and serves as SGA memory broker. It is a new process added to
Oracle 10g as part of automatic shared memory management.
Memory Monitor (maximum 1) MMON
MMON monitors SGA and performs various manageability related background tasks.
MMON, the Oracle 10g background process, used to collect statistics for the Automatic
Workload Repository (AWR).
Memory Monitor Light (maximum 1) MMNL
New background process in Oracle 10g. This process performs frequent and lightweight
manageability-related tasks, such as session history capture and metrics computation.
If you only change DB_NAME then old backups are still USABLE and you NO need to open
the database with RESETLOGS options. But you need to update the database name in
initialization parameter file and need to re-create password file.
The nid utility performs the validation of the controlfile and datafiles. Once the validation
successful it will prompt you to confirm the database name change operation.
Please see the below output (changing DBNAME from ORCL1 to ORCL5)
After successfully changing the database name the utility will shutdown the database.
5. Update DB_NAME in initialization parameter file with NEW Database name and rename
the parameter file to match NEW Database Name.
8. Change the database name in tnsnames.ora and listener.ora (in case of static) and
reload the listener
$ lsnrctl reload
For Windows: You must recreate the service so the correct name and parameter file are
used
C:\> oradim -delete -sid ORCL1
C:\> oradim -new -sid ORCL5 -intpwd password -startmode auto -pfile
c:\oracle\product\10.2.0\dbhome_1\dbs\spfileORCL5.ora
5. Update DB_NAME in initialization parameter file with NEW Database name and rename
the parameter file to match new DBNAME
Please note that you no need to open the database with resetlogs option as you only
changed database the DBNAME.
What is a latch?
Latches are low level serialization mechanisms used to protect shared data structures in the SGA. A
process acquires a latch when working with a structure in the SGA. It continues to hold the latch for
the period of time it works with the structure
A latch is a type of a lock that can be very quickly acquired and freed.
Latches are typically used to prevent more than one process from executing the same piece of code at
a given time.
List of latches that are of most concern to a DBA
BUFFER CACHE LATCHES:
There are two main latches which protect data blocks in the buffer cache.
- Cache buffers chains latch :- This latch is acquired whenever a block in the buffer cache is
accessed.
Cache Buffers Chains Latch waits are caused by contention where multiple sessions waiting to read the
same block.
Reduce logical I/O rates by tuning and minimizing the I/O requirements of the SQL involved.
Identify and reduce the contention for hot blocks.
- Cache buffers LRU chain latch:- This latch is acquired in order to introduce a new block into the
buffer cache and when writing a buffer back to disk.
Reduce contention for this by increasing the size of the buffer cache
LIBRARY CACHE:
- Library cache latch:- The library cache latch must be acquired in order to add a new statement to
the library cache. Ensure that the application is reusing as much as possible SQL statement.
If the application is already tuned, increase the SHARED_POOL_SIZE.
- Library cache pin latch:- This latch is acquired when a statement in the library cache is
reexecuted.
SHARED POOL RELATED LATCHES
- Shared pool latch: While the library cache latch protects operations withing the library cache, the
shared pool latch is used to protect critical operations when allocating and freeing memory in the
shared pool.
Ways to reduce the shared pool latch are, avoid hard parses when possible.
Row cache objects latch:- This latch comes into play when user processes are attempting to access
the cached data dictionary values.
Reduce contention for this latch is by increasing the size of the shared pool (SHARED_POOL_SIZE)
This is best illustrated with a simplified example of few seconds in the life of an Oracle shadow
process:
State Notes...
~~~~~ ~~~~~~~~
IDLE : Waiting for 'SQL*Net message from client'. Receives a SQL*Net packet requesting
'parse/execute' of a statement
ON CPU : decodes the SQL*Net packet.
WAITING : Waits for 'latch free' to obtain the a 'library cache' latch Gets the latch.
ON CPU : Scans for the SQL statement in the shared pool, finds a match, frees latch , sets up links to
the shared cursor etc.. & begins to execute.
WAITING : Waits for 'db file sequential read' as we need a block which is not in the buffer cache. Ie:
Waiting for an IO to complete.
ON CPU : Block read has completed so execution can continue. Constructs a SQL*Net packet to send
back to the user containing the first row of data.
WAITING : Waits on 'SQL*Net message to client' for an acknowledgement that the SQL*Net packet
was reliably delivered.
IDLE : Waits on 'SQL*Net message from client' for the next thing to do.
Most common wait events are..
Buffer Busy waits/Cache Buffers Chains Latch waits
This wait happens when a session wants to access a database block in the buffer cache but it cannot
as the buffer is "busy". The two main cases where this can occur are:
1.Another session is reading the block into the buffer
2.Another session holds the buffer in an incompatible mode to our request
Cache Buffers Chains Latch waits are caused by contention where multiple sessions waiting to read the
same block.
Typical solutions are:-
Look at the execution plan for the SQL being run and try to reduce the gets per executions which will
minimise the number of blocks being accessed and therefore reduce the chances of multiple sessions
contending for the same block.
Increase the PCTFREE for the table storage parameter. This will result in less rows per block.
Consider implementing reverse key indexes. (if range scans aren't commonly used against the
segment)
In v$session_wait, the P1, P2, and P3 columns identify the file number, block number, and buffer busy
reason codes, respectively.
"Read By Other Session" wait event.
When user sessions request for data, Oracle will first read the data from disk into the database buffer
cache. If two or more sessions request the same data, the first session will read the data into the
buffer cache while other sessions wait. In previous versions, this wait was classified under the "buffer
busy waits" event. However, in Oracle 10g and higher, this wait time is now broken out into the "read
by other session" wait event.
Excessive waits for this event are typically due to several processes repeatedly reading the same
blocks, e.g. many sessions scanning the same index or performing full table scans on the same table.
Tuning this issue is a matter of finding and eliminating this contention.
When a session is waiting on this event, an entry will be seen in the v$session_wait system view
giving more information on the blocks being waited for:
SELECT p1 "file#", p2 "block#"
FROM v$session_wait WHERE event = 'read by other session';
If information collected from the above query repeatedly shows that the same block (or range of
blocks) is experiencing waits, this indicates a "hot" block or object.
The following query will give the name and type of the object:
SELECT owner, segment_name, segment_type
FROM dba_extents WHERE file_id = &file
AND &block BETWEEN block_id AND block_id + blocks - 1
Log File Sync waits
Log file sync waits occur when sessions wait for redo data to be written to disk.
Typically this is caused by slow writes or committing too frequently in the application.
db file sequential read
Wait for an I/O read request to complete. A sequential read is usually a single-block read. This differs
from "db file scattered read" in that a sequential read reads data into contiguous memory (whilst a
scattered read reads multiple blocks and scatters them into different buffers in the SGA).
db file scattered read
This wait happens when a session is waiting for a multiblock IO to complete. This typically occurs
during full table scans or index fast full scans. Oracle reads up to
DB_FILE_MULTIBLOCK_READ_COUNT consecutive blocks at a time and scatters them into buffers in
the buffer cache.
direct path read
Direct path reads are generally used by Oracle when reading directly into PGA memory (as opposed to
into the buffer cache).
This style of read request is typically used for:
Sort I/Os when memory Sort areas are exhausted and temporary tablespaces are used to perform the
sort
Parallel Query slaves.
direct path write
This wait is seen for:
Direct load operations (eg: Create Table as Select (CTAS) may use this)
Parallel DML operations
Sort IO (when a sort does not fit in memory)
db file parallel write
DBW waits on "db file parallel write" when waiting for a parallel write to files and blocks to complete.
The db file parallel write occurs when the process, typically DBWR, has issued multiple I/O requests in
parallel to write dirty blocks from the buffer cache to disk, and is waiting for all requests to complete.
-------------------------------------------------V$Session_wait_history
From Oracle Database 10g a new view V$Session_wait_history will allow us to see the last few wait
events a session waited on.
The last 10 wait events that a session experienced can be displayed using the v$session_wait_history
view. The session has to be currently active. Once the session ends this information is not available.
We can use the seq# column to sort the wait events into the order in which the wait events occurred
for the session
different nodes.
From 10g release 2 the service can be setup to use load balancing advisory. This mean connections
can be routed using SERVICE TIME and THROUGHPUT. Connection load balancing means the goal of a
service can be changed, to reflect the type of connections using the service.
Transparent Application Failover (TAF)
Transparent Application Failover (TAF) is a feature of the Oracle Call Interface (OCI) driver at client
side. It enables the application to automatically reconnect to a database, if the database instance to
which the connection is made fails. In this case, the active transactions roll back.
Tnsnames Parameter: FAILOVER_MODE
e.g (failover_mode=(type=select)(method=basic))
Failover Mode Type can be Either SESSION or SELECT.
Session failover will have just the session to failed over to the next available node. With SELECT, the
select query will be resumed.
TAF can be configured with just server side service settings by using dbms_service package.
Fast Connection Failover (FCF)
Fast Connection Failover is a feature of Oracle clients that have integrated with FAN HA Events.
Oracle JDBC Implicit Connection Cache, Oracle Call Interface (OCI), and Oracle Data Provider for .Net
(ODP.Net) include fast connection failover.
With fast connection failover, when a down event is received, cached connections affected by the down
event are immediately marked invalid and cleaned up.
1)How can you check the files permission in Unix OS?
Ans: 'ls' command with the below option is used for checking files permission.
$ ls -altr
total 198
drwxr-xr-x 2 root root 4096 Aug 8 2008 srv
drwxr-xr-x 2 root root 4096 Aug 8 2008 mnt
drwxr-xr-x 3 root root 4096 Mar 7 05:10 home
drwxr-xr-x 7 root root 4096 Mar 7 05:47 lib64
2)How can you schedule job in Unix OS?
Ans: 'crontab' command is used for scheduling job in Unix OS.Crontab can be installed and removed as followed:
For commands that need to be executed repeatedly (e.g. hourly, daily or weekly), use crontab, which has the
following options:
crontab filename Install filename as your crontab file.
crontab -e Edit your crontab file.
crontab -l Show your crontab file.
man grep =>user manual for all command man has it own advantage.
chmod -R 775 /u01/test =>Grants permissions as read,write,execute to
owner,groups
useradd -d oracle =>For Creating Operating system user as Oracle.
9)Which command is used to copy or synchronizing two Directories in a secure way
on any Unix environment?
Ans : 'rsync' command can be used to copy or synchronize two directories.It is very
important command and very handy tool for copying files fast for a DBA,Ofcourse
'scp' can also be use.But I really like using 'rsync' .Below is the example:
Eg:
---[oracle@node1 HEALTH_CHECK_DB]$ rsync -av /u04/HEALTH_CHECK_DB/
/u05/SCRIPTS_DBA_TASKS/
building file list ... done
./
Database_status.sh
archive_gen.sql
c:&FileName._TESTDB1_20110509.html
c:&FileName._TESTDB2_20110509.html
db_monitor.sql
health_check.sql
sent 4225122 bytes received 158 bytes 8450560.00 bytes/sec
total size is 4224061 speedup is 1.00
[oracle@node1 HEALTH_CHECK_DB]$ cd ..
[oracle@node1 u04]$ cd /u05/SCRIPTS_DBA_TASKS/
[oracle@node1 SCRIPTS_DBA_TASKS]$ ls -altr
total 4176
-rwxrwxrwx 1 oracle dba 1815 Mar 27 23:53 archive_gen.sql
-rwxrwxrwx 1 oracle dba 2724 Mar 27 23:59 db_monitor.sql
-rw-r--r-- 1 oracle dba 1233385 May 9 11:40 health_check.sql
-rw-r--r-- 1 oracle dba 1421433 May 9 11:41
c:&FileName._TESTDB1_20110509.html
-rw-r--r-- 1 oracle dba 1564704 May 9 11:43
c:&FileName._TESTDB2_20110509.html
-rw-r--r-- 1 oracle dba 0 May 18 12:24 Database_status.sh
drwxrwxrwx 2 oracle dba 4096 May 18 12:24 .
drwxrwxr-x 9 oracle oinstall 4096 May 26 12:37 ..
-rwxrwxr-x 1 oracle dba 486 May 26 12:39
SCHEMA_CREATE_SCRIPT_TESTDB1_TESTDB2.sql
-rwxrwxr-x 1 oracle dba 846 May 26 14:06 profile_create.sql
-rwxrwxr-x 1 oracle dba 1252 May 27 20:44 crontab.oracle
-rwxrwxr-x 1 oracle dba 143 May 30 17:12 tablespace_create_script.sql
If you want to copy files from one linux(unix server) to other again it can be very
handy,below is the syntax:
* * * * *
user command to be executed
_ _ _ _ _
| | | | |
| | | | +----- day of week(0-6)the day of the week (Sunday=0)
| | | +------- month (1-12)
the month of the year
| | +--------- day of month (1-31) the day of the month
| +----------- hour (0-23)
the hour of the day
+------------- min (0-59)
the exact minute
#Run automatically every week - every 6th day of a week (Saturday=6)
* * * * 6 root /home/root/scripts/my_backup.sh
#TIP: Crontab script generator:
http://generateit.net/cron-job/
4. Q: What is OERR utility?
Oerr is an Oracle utility that extracts error messages with suggested actions from the standard Oracle message
files.
Oerr is installed with the Oracle Database software and is located in the ORACLE_HOME/bin directory.
Usage: oerr facility error
Facility is identified by the prefix string in the error message.
For example, if you get ORA-7300, "ora" is the facility and "7300"
is the error. So you should type "oerr ora 7300".
If you get LCD-111, type "oerr lcd 111", and so on. These include ORA, PLS, EXP, etc.
The error is the actual error number returned by Oracle.
Example:
$ oerr ora 600
ora-00600: internal error code, arguments: [%s], [%s], [%s], [%s], [%s], [%s], [%s], [%s]
*Cause: This is the generic internal error number for Oracle program
exceptions. This indicates that a process has encountered an
exceptional condition.
*Action: Report as a bug - the first argument is the internal error number
5. Q: How do you see Virtual Memory Statistics in Linux?
A: There is several ways to check mem stats: cat /proc/meminfo, top, free, vmstat...
"cat /proc/meminfo"
[user@host ~]$ cat /proc/meminfo
MemTotal:
5974140 kB
MemFree:
1281132 kB
Buffers:
250364 kB
Cached:
754636 kB
SwapCached:
68540 kB
Active:
3854048 kB
Inactive:
599072 kB
HighTotal:
5111744 kB
HighFree:
1018240 kB
LowTotal:
862396 kB
LowFree:
262892 kB
SwapTotal:
2096472 kB
SwapFree:
1880912 kB
Dirty:
364 kB
Writeback:
0 kB
Mapped:
3494544 kB
Slab:
203372 kB
CommitLimit: 5083540 kB
Committed_AS: 16863596 kB
PageTables:
19548 kB
VmallocTotal: 106488 kB
VmallocUsed:
3536 kB
VmallocChunk: 102608 kB
HugePages_Total:
0
HugePages_Free:
0
Hugepagesize:
2048 kB
"top"
[user@host ~]$ top (sort by memory consumption by pressing SHIFT+O and then press "n")
"free"
[user@host ~]$ free
total
used
free
shared buffers
Mem:
5974140 4693336 1280804
-/+ buffers/cache: 3688336 2285804
Swap:
2096472
215560 1880912
cached
0
250364
754636
A: shmmax maximum size (in bytes) for a UNIX/Linux shared memory segment
DESCRIPTION (docs.hp.com)
Shared memory is an efficient InterProcess Communications (IPC) mechanism.
One process creates a shared memory segment and attaches it to its address space.
Any processes looking to communicate with this process through the shared memory segment, then attach the
shared memory segment to their corresponding address spaces as well.
Once attached, a process can read from or write to the segment depending on the permissions specified while
attaching it.
How to display info about shmmax:
[user@host ~]$ cat /etc/sysctl.conf |grep shmmax
kernel.shmmax=3058759680
9. Q: Swap partition must be how much the size of RAM?
A: A tricky question coz opinions about this are always a good topic for any discussions.
In the past; once upon the time, when systems used to have 32/64 or max 128Mb of RAM memory it was
recommended to allocate as twice as your RAM for swap partition.
Nowadays we do have a bit more memory for our systems.
An advice: always take softwares vendor recommended settings into account and then decide.
For example, Oracle recommends always minimum 2GB for swap and more for their products - depends of the
product and systems size.
Example of ORACLE Database 11g recommendations:
Amount of RAM
Swap Space
Between 1 GB and 2 GB
1.5 times the size of RAM
Between 2 GB and 16 GB
Equal to the size of RAM
More than 16 GB
16 GB
Another common example:
Equal the size of RAM, if amount of RAM is less than 1G
Half the size of RAM for RAM sizes from 2G to 4G.
More than 4G of RAM, you need 2G of Swap.
TIP: To determine the size of the configured swap space in Linux, enter the following command:
[user@host]~ grep SwapTotal /proc/meminfo
SwapTotal:
2096472 kB
To determine the available RAM and swap space use "top" or "free".
11. Q: How do you see how many memory segments are acquired by Oracle Instances?
A: ipcs - provides information on the ipc facilities for which the calling process has read acccess
#UNIX: SEGSZ
root> ipcs -pmb
IPC status from <running system> as of Mon Sep 10 13:56:17 EDT 2001
T
ID
KEY
MODE
OWNER GROUP SEGSZ CPID
Shared Memory:
m
2400 0xeb595560 --rw-r----- oracle dba 281051136 15130
m
601 0x65421b9c --rw-r----- oracle dba 142311424 15161
#Linux: bytes
[user@host ~]$ icps
------ Shared Memory Segments -------key
shmid
owner
perms
bytes
nattch
0x00000000 32769
oracle 644
122880
2
status
dest
12. Q: How do you see which segment belongs to which database instances?
A: This can be achieved with help of ipcs tool and sqlplus; oradebug ipc
#Linux
[user@host ~]$ icps
------ Shared Memory Segments -------key
shmid
owner
perms
bytes
nattch
0x00000000 32769
oracle 644
122880
2
status
dest
#UNIX:
root> ipcs -pmb
IPC status from <running system> as of Mon Sep 10 13:56:17 EDT 2001
T
ID
KEY
MODE
OWNER GROUP SEGSZ CPID
Shared Memory:
m
32769 0xeb595560 --rw-r----- oracle dba 281051136 15130
m
601 0x65421b9c --rw-r----- oracle dba 142311424 15161
m
702 0xe2fb1874 --rw-r----- oracle dba 460357632 15185
m
703 0x77601328 --rw-r----- oracle dba 255885312 15231
#record value of shmid "32769" (ID in UNIX)
[user@host ~]$ sqlplus /nologin
SQL> connect system/manager as sysdba;
SQL> oradebug ipc
#Information have been written to the trace file. Review it.
In case of having multiple instances, grep all trace files for shmid 32769 to identify the database instance
corrsponding to memory segments.
#scrap of trace file MY_SID_ora_17727.trc:
Area Subarea Shmid
Stable Addr
Actual Addr
1
1
32769 000000038001a000 000000038001a000
13. Q: What is VMSTAT?
A:
It reports information about processes, memory, paging, block IO, traps, and cpu activity.
[user@host ~]$ vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---r b swpd free buff cache si so bi bo in cs us sy id wa
3 0 170224 121156 247288 1238460 0 0 18 16 1
0 3 2 95 0
14. Q: How do you set Kernel Parameters in Red Hat Linux, AIX and Solaris?
"Symbolic links" (symlinks/soft link) are a special file type in which the link file actually refers to a different file or
directory by name.
When most operations (opening, reading, writing, and so on) are passed the symbolic link file, the kernel
automatically "dereferences" the link and operates on the target
of the link. But remove operation works on the link file itself, rather than on its target!
A "hard link" is another name for an existing file; the link and the original are indistinguishable.
They share the same inode, and the inode contains all the information about a file.
It will be correct to say that the inode is the file. Hard link is not allowed for directory (This can be done by using
mount with --bind option)!
ln - makes links between files. By default, it makes hard links; with the "-s" option, it makes symbolic (soft) links.
Synopses:
ln [OPTION]... TARGET [LINKNAME]
ln [OPTION]... TARGET... DIRECTORY
EXAMPLE:
#hard links
[user@host ~]$ touch file1
[user@host ~]$ ln file1 file2
[user@host ~]$ ls -li
total 0
459322 -rw-r--r-- 2 userxxx users 0 May 6 16:19 file1
459322 -rw-r--r-- 2 userxxx users 0 May 6 16:19 file2 (the same inode, rights, size, time and so on!)
[user@host ~]$ mkdir dir1
[user@host ~]$ ln dir1 dir2
ln: `dir1': hard link not allowed for directory
#symbolic links
[user@host ~]$ rm file2 #hard link removed
[user@host ~]$ ln -s file1 file2 #symlink to file
[user@host ~]$ ln -s dir1 dir2
#symlink to directory
[user@host ~]$ ls -li
total 12
459326 drwxr-xr-x 2 userxxx users 4096 May 6 16:38 dir1
459327 lrwxrwxrwx 1 userxxx users 4 May 6 16:39 dir2 -> dir1 (dir2 refers to dir1)
459322 -rw-r--r-- 1 userxxx users
0 May 6 16:19 file1
459325 lrwxrwxrwx 1 userxxx users 5 May 6 16:20 file2 -> file1 (different inode, rights, size and so on!)
[user@host ~]$ rm file2 #will remove a symlink NOT a targed file; file1
[user@host ~]$ rm dir2
[user@host ~]$ ls -li
[user@host ~]$ ls -li
total 4
459326 drwxr-xr-x 2 userxxx users 4096 May 6 16:38 dir1
459322 -rw-r--r-- 1 userxxx users 0 May 6 16:19 file1
[user@host ~]$ info coreutils ln #(should give you access to the complete manual)
A: This file is being read by ORACLE software, created by root.sh script which is being executed manually during the software
installation and updated by the Database Configuration Assistant (dbca) during the database creation.
File location: /etc/oratab
ENTRY SYNTAX:
$ORACLE_SID:$ORACLE_HOME:<N|Y>:
$ORACLE_SID - Oracle System Identifier (SID environment variable)
$ORACLE_HOME - Database home directory
<N|Y> Start or not resources at system boot time by the start/stop scripts if configured.
Multiple entries with the same $ORACLE_SID are not allowed.
EXAMPLES:
0 stopped,
0 zombie
A:
nice - Runs COMMAND with an adjusted scheduling priority. When no COMMAND specified prints the current scheduling
priority.
ADJUST is 10 by default. Range goes from -20 (highest priority) to 19 (lowest).
renice - alters priority of running processes
EXAMPLES: (NI in top indicates nice prio)
[user@host ~]$ mc
[user@host ~]$ top
PID USER
PR NI
1896 userxxx 17
0
TIME+ COMMAND
0:00.03 mc