Which background process writes alert log

Being familiar with normal behavior in turn helps you recognize when something is wrong. This section describes some of the options available to you for monitoring the operation of your database. A server-generated alert is a notification from the Oracle Database server of an impending problem. The notification may contain suggestions for correcting the problem. Notifications are also provided when the problem condition has been cleared. Alerts are automatically generated when a problem occurs or when data does not match expected values for metrics, such as the following:.

Server-generated alerts can be based on threshold levels or can issue simply because an event has occurred. Threshold-based alerts can be triggered at both threshold warning and critical levels.

The value of these levels can be customer-defined or internal values, and some alerts have default threshold levels which you can change if appropriate. Examples of alerts not based on threshold levels are:. Oracle Enterprise Manager reads this queue and provides notifications about outstanding server alerts, and sometimes suggests actions for correcting the problem.

The alerts are displayed on the Enterprise Manager console and can be configured to send email or pager notifications to selected administrators. If an alert cannot be written to the alert queue, a message about the alert is written to the Oracle Database alert log. Background processes periodically flush the data to the Automatic Workload Repository to capture a history of metric values. The most convenient way to set and view threshold values is to use Enterprise Manager.

In this example, a warning alert is issued when CPU time exceeds microseconds for each user call and a critical alert is issued when CPU time exceeds 10, microseconds for each user call. The arguments include:.

The observation period is set to 1 minute. This period specifies the number of minutes that the condition must deviate from the threshold value before the alert is issued. The number of consecutive occurrences is set to 2. This number specifies how many times the metric value must violate the threshold values before the alert is generated. In this example, the service name is main.

For example:. You must also assign the enqueue privilege to the user. Each server and background process can write to an associated trace file. When an internal error is detected by a process, it dumps information about the error to its trace file. Some of the information written to a trace file is intended for the database administrator, and other information is for Oracle Support Services.

Trace file information is also used to tune applications and instances. The alert log is a special trace file. The alert log of a database is a chronological log of messages and errors, and includes the following items:. The values of all initialization parameters that had nondefault values at the time the database and instance start. Oracle Database uses the alert log to record these operations as an alternative to displaying the information on an operator's console although some systems also display information on the console.

If an operation is successful, a "completed" message is written in the alert log, along with a timestamp. Check the alert log and other trace files of an instance periodically to learn whether the background processes have encountered errors. For example, when the log writer process LGWR cannot write to a member of a log group, an error message indicating the nature of the problem is written to the LGWR trace file and the database alert log.

Oracle Database also writes values of initialization parameters to the alert log, in addition to other important statistics. To control the size of an alert log, you must manually delete the file when you no longer need it. Otherwise the database continues to append to the file.

You can safely delete the alert log while the instance is running, although you should consider making an archived copy of it first. This archived copy could prove valuable if you should have a future problem that requires investigating the history of an instance. Background processes always write to a trace file when appropriate. In the case of the ARC n background process, it is possible, through an initialization parameter, to control the amount and type of trace information that is produced.

Other background processes do not have this flexibility. Trace files are written on behalf of server processes whenever internal errors occur. Optionally, you can request that trace files be generated for server processes. This example enables the SQL trace facility for a specific session:. If shared server is enabled, each session using a dispatcher is routed to a shared server process, and trace information is written to the server trace file only if the session has enabled tracing or if an error is encountered.

Therefore, to track tracing for a specific session that connects using a dispatcher, you might have to explore several shared server trace files. To help you, Oracle provides a command line utility program, trcsess , which consolidates all trace information pertaining to a user session in one place and orders the information by time.

Locks are mechanisms that prevent destructive interaction between transactions accessing the same resource. The resources can be either user objects, such as tables and rows, or system objects not visible to users, such as shared data structures in memory and data dictionary rows.

Oracle Database automatically obtains and manages necessary locks when executing SQL statements, so you need not be concerned with such details. However, the database also lets you lock data manually. A deadlock can occur when two or more users are waiting for data locked by each other. Deadlocks prevent some transactions from continuing to work. Oracle Database automatically detects deadlock situations and resolves them by rolling back one of the statements involved in the deadlock, thereby releasing one set of the conflicting row locks.

Oracle Database is designed to avoid deadlocks, and they are not common. Most often they occur when transactions explicitly override the default locking of the database. Deadlocks can affect the performance of your database, so Oracle provides some scripts and views that enable you to monitor locks.

The utllockt. The location of this script file is operating system dependent. A second script, catblock. Oracle Database Reference contains detailed descriptions of these views.

Oracle Database Concepts contains more information about locks. Wait events are statistics that are incremented by a server process to indicate that it had to wait for an event to complete before being able to continue processing. A session could wait for a variety of reasons, including waiting for more input, waiting for the operating system to complete a service such as a disk write, or it could wait for a lock or latch.

When a session is waiting for resources, it is not doing any useful work. A large number of waits is a source of concern. Oracle provides several views that display wait event statistics. A discussion of these views and their role in instance tuning is contained in Oracle Database Performance Tuning Guide.

This section lists some of the data dictionary views that you can use to monitor an Oracle Database instance. These views are general in their scope.

Other views, more specific to a process, are discussed in the section of this book where the process is described. Skip Headers. A server process can be either of the following: A dedicated server process , which services only one user process A shared server process , which can service multiple user processes Your database is always enabled to allow dedicated server processes, but you must specifically configure and enable shared server by setting one or more initialization parameters.

In the following situations, however, users and administrators should explicitly connect to an instance using a dedicated server process: To submit a batch job for example, when a job can allow little or no idle time for the server process To use Recovery Manager RMAN to back up, restore, or recover a database To request a dedicated server connection when Oracle Database is configured for shared server, users must connect using a net service name that is configured to use a dedicated server.

Shared Server Processes Consider an order entry system with dedicated server processes. See Also: Oracle Database Net Services Administrator's Guide for more detailed information about shared server, including features such as connection pooling and session multiplexing.

Configuring Oracle Database for Shared Server Shared memory resources are preconfigured to allow the enabling of shared server at run time. See Also: Oracle Database Reference for more information about these initialization parameters. The following example shows how you can use this parameter: Assume a database is being used by a telemarketing center staffed by agents. A protocol address is required and is specified using one or more of the following attributes: Attribute Description ADDRESS Specify the network protocol address of the endpoint on which the dispatchers listen.

A TICK is a unit of time in terms of which the connection pool timeout can be specified. Used for connection pooling. Set the alias to a name that is resolved through a naming method. POOL Used to enable connection pooling. Altering the Number of Dispatchers You can control the number of dispatcher processes in the instance. Monitoring Shared Server The following views are useful for obtaining information about your shared server configuration and for monitoring performance. May be useful when tuning shared server.

See Also: Oracle Database Reference for detailed descriptions of these views Oracle Database Performance Tuning Guide for specific information about monitoring and tuning shared server. About Oracle Database Background Processes To maximize performance and accommodate many users, a multiprocess Oracle Database system uses background processes.

Archiver ARC n One or more archiver processes copy the redo log files to archival storage when they are full or a log switch occurs. Recoverer RECO The recoverer process is used to resolve distributed transactions that are pending because of a network or system failure in a distributed database.

Dispatcher D nnn Dispatchers are optional background processes, present only when the shared server configuration is used.

About Parallel Execution Servers When an instance starts up, Oracle Database creates a pool of parallel execution servers which are available for any parallel operation. Managing Processes for External Procedures External procedures are procedures written in one language that are called from another program in a different language.

Note: The external library DLL file must be statically linked. In other words, it must not reference any external symbols from other external libraries DLL files. Oracle Database does not resolve such symbols, so they can cause your external procedure to fail.

Terminating Sessions Sometimes it is necessary to terminate current user sessions. This section describes the various aspects of terminating sessions, and contains the following topics: Identifying Which Session to Terminate Terminating an Active Session Terminating an Inactive Session When a session is terminated, any active transactions of the session are rolled back, and resources held by the session such as locks and memory areas are immediately released and available to other sessions.

See Also: Oracle Database Reference for a description of the status values for a session. Monitoring the Operation of Your Database It is important that you monitor the operation of your database on a regular basis. Server-Generated Alerts A server-generated alert is a notification from the Oracle Database server of an impending problem. Alerts are automatically generated when a problem occurs or when data does not match expected values for metrics, such as the following: Physical Reads Per Second User Commits Per Second SQL Service Response Time Server-generated alerts can be based on threshold levels or can issue simply because an event has occurred.

The name of the instance is set to inst1. See Also: Oracle Database Reference for information on static data dictionary views and dynamic performance views. There are many background processes, associated with each instance e. Each server and background process can write to an associated trace file.

When an internal error is detected by a process , it dumps information about the error to its trace file. Some of the information written to a trace file is intended for the database administrator, and other information is for Oracle Support Services. Trace file information is also used to tune applications and instances.

The alert log is a chronological log of database messages and errors The alert log is maintained as both an XML-formatted file and a text-formatted file. Typical messages found in this file is: database startup, shutdown, log switches, space errors, recovering the database , creating or dropping a tablespace, and some other entries about significant database events.

There is also a text-formatted version of the alert log stored in the ADR for backward compatibility. However, Oracle recommends that any parsing of the alert log contents be done with the XML-formatted version, because the text format is unstructured and may change from release to release. Check the alert log and trace files of an instance periodically to learn whether the background processes have encountered errors.

For example, when the log writer process LGWR cannot write to a member of a log group, an error message indicating the nature of the problem is written to the LGWR trace file and the alert log. Errors occurring during the automatic refresh of a materialized view.

The values of all initialization parameters that had non-default values at the time the database and instance startup. The archiver writes to it. When a background process detects that another has died, the former writes to the alert log before panicking the instance and killing it. To find the location of alert log file we can find by below command. Enjoy Newer Post Older Post Home.