Valid values are integers greater than or equal to zero. If an id setting is omitted, then the numresults setting applies to all dimensions as a global setting. Valid values are true to return counts and false to not return counts. If you omit an id setting, then the showcounts setting applies to all dimension values a global setting. Valid values are true to show synonyms and false to not show synonyms. If you omit id setting, then the synonyms setting applies to all dimension values a global setting.
Valid values are 0 and 1. This level might be enabled broadly occasionally on a production environment to debug issues with the software. Enabling logging at this level might have a small performance impact, but not to the point of making the software unusable.
A fairly detailed trace or debug message has been written. The message is clear enough to be understood by Oracle Support Services engineers who have a deep knowledge of the product but might not know full details of the internal implementation.
High performance impact. This level mustn't be enabled on a production environment, except on special situations to debug issues with the software.
A highly detailed trace or debug message has been written. The message is intended for an Oracle developer working on the software who knows enough details about the implementation of the subsystem that generates the message.
Very high performance impact. This level isn't expected to be enabled in a production environment and developers use it only to debug the software on a test or development environment. In the following log configuration file example, in the Notification message category, only level 1 messages are logged. If the log level is set to 0, then nothing is logged for that message category.
Avoid manually changing the default settings in the log file. Use Fusion Middleware Control to make changes. Log file rotation is the creation of new log files, when the file exceeds a specified threshold or date.
Whenever a log file exceeds the size that's specified by this setting, then the existing Scheduler log file is renamed, and a new log file is created. Additionally, a log file date that's older than the MaximumLogAgeDay setting is deleted.
Different components have different log file names and different settings within their log configuration files. Determine whether or not the log apply services might be unexpectedly stopped. See the ORA for physical standby databases or ORA for logical standby databases error description and solution statement for more help. If you want to suppress the error while you investigate the problem, you can temporarily disable broker management of the database. If the current status of the standby database is normal:.
Check to see if log files are building up because the value of the DelayMins property is set too large. Log apply services will delay applying the archived redo log files on the standby database for the number of minutes specified. If you cannot see any errors, compare the archive rate to the apply rate on the Performance page in Cloud Control to see if the apply rate is lower than the archive rate.
If the broker requests are not completing within the normal timeout parameters, try these actions to solve the problem. If the primary database is flashed back, then the standby databases in the configuration must be also be flashed back or re-created to be viable targets for switchovers or failovers. The broker will report errors for the standby databases if the primary database has been flashed back. For more information about restoring the viability of a standby database that was disabled by the broker, see Reenabling Disabled Databases After a Role Change.
If you receive this error, and your database is not managed by Oracle Clusterware, then you must manually start the instance to complete or continue the broker operation. The troubleshooting information in this section applicable only to databases that are not managed by Oracle Clusterware.
You will have to connect to another running instance to issue this command :. The static service name specified in the value of the StaticConnectIdentifer instance property should be registered with the listener specified in the property value.
The default value for the static service name is of the following form:. See Prerequisites for more information about this, and other prerequisites, for using the broker. Confirm that the static service name is registered with the listener specified in the StaticConnectIdentifer configurable property value by using the Listener Control utility's status command.
If the static service name is properly registered with the listener, it will be included in the output generated by the following command:. If the switchover fails due to problems with the configuration, then the broker reports any problems it encounters in the alert log files or in the broker log files. See Sources of Diagnostic Information for more information about log files. If the reported problems can be corrected, you can retry the switchover operation and it will usually succeed.
If the reported problems cannot be corrected or the switchover operation fails even after correcting the reported problems, then you can choose another database for the switchover or restore the configuration to its pre-switchover state and then retry the switchover. If fast-start failover is enabled, the broker does not allow switchover to any standby database except to the target standby database.
Although it is possible for a failover operation to fail, it is unlikely. Verify the state and status of the standby database by viewing its information on the Data Guard Overview page. Run the Verify operation after the switchover completes to examine the alert log file of the new primary database and to verify the status of the configuration. Problem: The switchover may fail during verification checks done by Data Guard broker for example, redo transport services might return errors on a database that is involved in the switchover.
Solution: Choose another database for the switchover or fix the problem by transporting the archived redo log files. A lthough it is possible for a failover to stop, it is unlikely. If an error occurs, it is likely to happen when the standby database is transitioning to the primary role.
If the error status indicates that this problem occurred, use these general guidelines to fix the problem:. Investigate the error information provided by the broker to find the source of the problem and correct it. Problem: The primary database is still running. Enterprise Manager tries to detect if the primary database is still running. However, if the primary database is still running and the Enterprise Manager cannot detect that it is running, the failover will not be successful.
Solution: If the primary database is still running but can no longer function as a primary database, shut it down and retry the failover. The observer continuously monitors the fast-start failover environment to ensure the primary database is available. Installing and starting the observer is an integral part of enabling fast-start failover. The following sections describe techniques for troubleshooting the observer:.
Only one observer can be associated with the broker configuration at any given time. If you attempt to start a second observer, one of the following errors is returned:. If the observer host machine crashes, the broker configuration is no longer observed and fast-start failover is no longer possible. In this case, you may have to move the observer to a new host if the original host machine cannot be repaired in a timely fashion.
To move the observer, you must stop the first observer and then start a new observer on another host. Now, you may start the new observer. After the observer is started, it prints its failover and reinstatement actions to the console in which it was started. All the observer output is then recorded in a file named observer. This chapter contains the following topics: Section
0コメント