Что такое oracle restart
Благодаря Oracle Restart различные компоненты Oracle автоматически перезапускаются после аппаратных или программных сбоев и всякий раз, когда Ваш хостовый компьютер базы данных перезапускается.
Перезапуск Oracle выполняет периодические проверки, чтобы контролировать работоспособность этих компонентов. Если операция проверки не срабатывает для компонента, компонент выключается и перезапускается.
Перезапуск Oracle используется только в средах с единственным экземпляром (не в кластерах). Для среды Реальных Кластеров Приложений Oracle (Oracle RAC) функциональность автоматического перезапуска компонентов обеспечивается ПО Кластеризации Oracle.
Перезапуск Oracle гарантирует, что компоненты Oracle запускаются в надлежащем порядке с учетом компонентных зависимостей. Например, если файлы базы данных хранятся в дисковых группах ASM, то прежде, чем запустить экземпляр базы данных, Oracle Restart гарантирует, что экземпляр ASM будет запущен, а необходимые дисковые группы будут смонтированы. Аналогично, если компонент должен быть выключен, Oracle Restart гарантирует, что сначала будут выключены должным образом зависимые компоненты.
Перезапуск Oracle также управляет программной зависимостью между экземплярами базы данных и прослушивателем Сети Oracle. При запуске экземпляра базы данных, Oracle Restart пытается запустить прослушивателя. Если запуск прослушивателя не срабатывает, база данных все равно запускается. Если позднее происходит сбой прослушивателя, Oracle Restart не завершает работу и не перезапускает какие-либо экземпляры базы данных.
Вы запускаете Oracle Restart посредством утилиты Управления ПО Кластеризации (crsctl).
Перезапуск Oracle включает утилиту Управления Сервером (srvctl), которую Вы используете, чтобы запускать и останавливать компоненты, управляемые Oracle Restart.
Отметьте: Утилита srvctl располагается как в каталоге $ORACLE_HOME/bin для программного обеспечения Инфраструктуры Грида, так и в каталоге $ORACLE_HOME/bin для программного обеспечения базы данных Oracle. Следует использовать утилиту srvctl программного обеспечения базы данных Oracle при запуске базы данных Oracle. И следует использовать утилиту srvctl программного обеспечения Инфраструктуры Грида при запуске экземпляра ASM или прослушивателя.
Oracle Restart improves the availability of your Oracle database. When you install Oracle Restart, various Oracle components can be automatically restarted after a hardware or software failure or whenever your database host computer restarts. Table 4-1 lists these components.
Table 4-1 Oracle Components Automatically Restarted by Oracle Restart
Oracle Restart can accommodate multiple databases on a single host computer.
Oracle Net listener
Does not include the default service created upon installation because it is automatically managed by Oracle Database, and does not include any default services created during database creation.
Oracle Automatic Storage Management (Oracle ASM) instance
Oracle ASM disk groups
Restarting a disk group means mounting it.
Oracle Notification Services (ONS)
In a standalone server environment, ONS can be used in Oracle Data Guard installations for automating failover of connections between primary and standby database through Fast Application Notification (FAN). ONS is a service for sending FAN events to integrated clients upon failover.
Oracle Restart runs periodic check operations to monitor the health of these components. If a check operation fails for a component, the component is shut down and restarted.
Oracle Restart is used in standalone server (non-clustered) environments only. For Oracle Real Application Clusters (Oracle RAC) environments, the functionality to automatically restart components is provided by Oracle Clusterware.
Oracle Restart runs out of the Oracle Grid Infrastructure home, which you install separately from Oracle Database homes. See the Oracle Database Installation Guide for your platform for information about installing the Oracle Grid Infrastructure home.
Oracle Automatic Storage Management Administrator's Guide for information about Oracle Automatic Storage Management
About Starting and Stopping Components with Oracle Restart
Oracle Restart automatically restarts various Oracle components when required, and automatically stops Oracle components in an orderly fashion when you manually shut down your system. There may be times, however, when you want to manually start or stop individual Oracle components. Oracle Restart includes the Server Control (SRVCTL) utility that you use to manually start and stop Oracle Restart–managed components. When Oracle Restart is in use, Oracle strongly recommends that you use SRVCTL to manually start and stop components.
After you stop a component with SRVCTL, Oracle Restart does not automatically restart that component if a failure occurs. If you then start the component with SRVCTL, that component is again available for automatic restart.
Oracle utilities such as SQL*Plus, the Listener Control utility ( LSNRCTL ), and ASMCMD are integrated with Oracle Restart. If you shut down the database with SQL*Plus, Oracle Restart does not interpret this as a database failure and does not attempt to restart the database. Similarly, if you shut down the Oracle ASM instance with SQL*Plus or ASMCMD , Oracle Restart does not attempt to restart it.
An important difference between starting a component with SRVCTL and starting it with SQL*Plus (or another utility) is the following:
When you start a component with SRVCTL, any components on which this component depends are automatically started first, and in the proper order.
When you start a component with SQL*Plus (or another utility), other components in the dependency chain are not automatically started; you must ensure that any components on which this component depends are started.
In addition, Oracle Restart enables you to start and stop all of the components managed by Oracle Restart in a specified Oracle home using a single command. The Oracle home can be an Oracle Database home or an Oracle Grid Infrastructure home. This capability is useful when you are installing a patch.
About Startup Dependencies
Oracle Restart ensures that Oracle components are started in the proper order, in accordance with component dependencies. For example, if database files are stored in Oracle ASM disk groups, then before starting the database instance, Oracle Restart ensures that the Oracle ASM instance is started and the required disk groups are mounted. Likewise, if a component must be shut down, Oracle Restart ensures that dependent components are cleanly shut down first.
Oracle Restart also manages the weak dependency between database instances and the Oracle Net listener (the listener): When a database instance is started, Oracle Restart attempts to start the listener. If the listener startup fails, then the database is still started. If the listener later fails, Oracle Restart does not shut down and restart any database instances.
2.2 About Automating Database Shutdown and Startup
Oracle recommends that you configure the system to automatically start Oracle Database when the system starts, and to automatically shut it down when the system shuts down. Automating database startup and shutdown guards against incorrect database shutdown.
To automate database startup and shutdown, use the dbstart and dbshut scripts, which are located in the $ORACLE_HOME/bin directory. The scripts refer to the same entries in the oratab file, which are applied on the same set of databases. You cannot, for example, have the dbstart script automatically start sid1 , sid2 , and sid3 , and have the dbshut script shut down only sid1 . However, you can specify that the dbshut script shuts down a set of databases while the dbstart script is not used at all. To do this, include a dbshut entry in the system shutdown file, but do not include the dbstart entry in the system startup files.
The init command in the operating system documentation for more information about system startup and shutdown procedures
2.2.1 Automating Database Startup and Shutdown
To automate database startup and shutdown by using the dbstart and dbshut scripts:
- Log in as the root user.
- Edit the oratab file for the platform.
To open the file, use one of the following commands:
On Oracle Solaris:
On IBM AIX on POWER Systems (64-Bit) and Linux:
Database entries in the oratab file are displayed in the following format:
In this example, the values Y and N specify whether you want the scripts to start or shut down the database, respectively. For each database for which you want to automate shutdown and startup, first determine the instance identifier (SID) for that database, which is identified by the SID in the first field. Then, change the last field for each to Y .
You can set dbstart to autostart a single-instance database which uses an Automatic Storage Management installation auto-started by Oracle Clusterware. This is the default behavior for an Automatic Storage Management cluster. To do this, you must change the oratab entry of the database and the Automatic Storage Management installation to use a third field with the value W and N , respectively. These values specify that dbstart auto-starts the database only after the Automatic Storage Management instance is started.
If you add new database instances to the system and automate the startup for them, then you must edit the entries for those instances in the oratab file.
Linux and Oracle Solaris
IBM AIX on POWER Systems (64-Bit)
Change the value of the ORA_HOME environment variable to specify the Oracle home directory for the installation. Change the value of the ORA_OWNER environment variable to the user name of the owner of the database installed in the Oracle home directory (typically, oracle ).
This script can only stop Oracle Net listener for which a password has not been set. In addition, if the listener name is not the default name, LISTENER , then you must specify the listener name in the stop and start commands:
Explore the basics of Oracle Restart (integrated with Oracle Data Guard) when using it with Oracle SE in a standby database configuration.
About Starting and Stopping Oracle Restart
The CRSCTL utility starts and stops Oracle Restart. You can also use the CRSCTL utility to enable or disable Oracle high availability services. Oracle Restart uses Oracle high availability services to start and stop automatically the components managed by Oracle Restart. For example, Oracle high availability services daemons automatically start databases, listeners, and Oracle ASM instances. When Oracle high availability services are disabled, none of the components managed by Oracle Restart are started when a node is rebooted.
Typically, you use the CRSCTL utility when you need to stop all of the running Oracle software in an Oracle installation. For example, you might need to stop Oracle Restart when you are installing a patch or performing operating system maintenance. When the maintenance is complete, you use the CRSCTL utility to start Oracle Restart.
Overview of Fast Application Notification
FAN is a notification mechanism that Oracle Restart can use to notify other processes about configuration changes that include service status changes, such as UP or DOWN events. FAN provides the ability to immediately terminate inflight transaction when an instance or server fails. Integrated Oracle clients receive the events and respond. Applications can respond either by propagating the error to the user or by resubmitting the transactions and masking the error from the application user. When a DOWN event occurs, integrated clients immediately clean up connections to the terminated database. When an UP event occurs, the clients create new connections to the new primary database instance.
Oracle Restart publishes FAN events whenever a managed instance or service goes up or down. After a failover, the Oracle Data Guard Broker (broker) publishes FAN events. These FAN events can be used in the following ways:
FAN server-side callouts can be configured on the database tier.
For DOWN events, such as a failed primary database, FAN provides immediate notification to the clients so that they can failover as fast as possible to the new primary database. The clients do not wait for a timeout. The clients are notified immediately, and they must be configured to failover when they are notified.
For UP events, when services and instances are started, new connections can be created so that the application can immediately take advantage of the extra resources.
Through server-side callouts, you can also use FAN to:
Log status information
Page DBAs or open support tickets when resources fail to start
Automatically start dependent external applications that must be co-located with a service
FAN events are published using ONS and Oracle Streams Advanced Queuing queues. The queues are configured automatically when you configure a service. You must configure ONS manually using SRVCTL commands.
The Connection Manager (CMAN) and Oracle Net Services listeners are integrated with FAN events, enabling the CMAN and the listener to immediately de-register services provided by the failed instance and to avoid erroneously sending connection requests to a failed database.
Oracle Data Guard Broker for information about FAN events in an Oracle Data Guard environment
The Maximum Availability Architecture (MAA) white paper about client failover:
2.1 Stopping and Starting Oracle Processes
This section describes how to stop and start Oracle processes. It contains the following topics:
2.1.1 Stopping and Starting Oracle Database and Oracle Automatic Storage Management Instances
This section describes how to stop and start Oracle Database and Oracle Automatic Storage Management instances and contains the following topics:
2.1.1.1 Stopping an Oracle Database or Oracle Automatic Storage Management Instance
Do not stop an Oracle Automatic Storage Management instance until you have stopped all Oracle Database instances that use Oracle Automatic Storage Management instance to manage their storage.
To stop an Oracle Database or Oracle Automatic Storage Management instance:
- Run the following commands to identify the SID and Oracle home directory for the instance that must be shut down:
On Oracle Solaris:
On other operating systems:
The oratab file contains lines similar to the following, which identify the SID and corresponding Oracle home directory for each database or Oracle Automatic Storage Management instance on the system:
Oracle recommends that you use the plus sign (+) as the first character in the SID of Oracle Automatic Storage Management instances.
Bourne, Bash, or Korn shell:
When prompted, specify the SID for the instance.
After the instance shuts down, you can quit SQL*Plus.
2.1.1.2 Restarting an Oracle Database or Oracle Automatic Storage Management Instance
If the database instance uses Oracle Automatic Storage Management for storage management, then you must start the Oracle Automatic Storage Management instance before you start the database instance.
To restart an Oracle Database or Oracle Automatic Storage Management instance:
- Repeat steps 1 and 2, if required, to set the ORACLE_SID and ORACLE_HOME environment variables to identify the SID and Oracle home directory for the instance you want to start.
- Run the following commands to start the instance:
After the instance starts, you can exit from SQL*Plus.
2.1.2 Stopping and Starting Oracle Restart
To stop or start Oracle Restart, run the following command:
Start: This option is used to start Oracle Restart
Syntax and Options:
Stop: This option is used to stop Oracle Restart
Syntax and Options:
Oracle Database Administrator's Guide for more information about the srvctl commands
Application High Availability with Services and FAN
Oracle Database focuses on maintaining service availability. With Oracle Restart, Oracle services are designed to be continuously available. Oracle Restart monitors the database and its services and, when configured, sends event notifications using FAN.
Managing Unplanned Outages
If Oracle Restart detects an outage, then it isolates the failed component and recovers the dependent components. If the failed component is the database instance, then after Oracle Data Guard fails over to the standby database, Oracle Restart on the new primary database starts any services defined with the current role.
FAN events are published by Oracle Restart and the Oracle Data Guard Broker through ONS and Advanced Queuing. You can also perform notifications using FAN callouts.
Oracle Restart does not run callouts with guaranteed ordering. Callouts are run asynchronously, and they are subject to scheduling variability.
With Oracle Restart, restart and recovery are automatic, including the restarting of the subsystems, such as the listener and the Oracle Automatic Storage Management (Oracle ASM) processes, not just the database. You can use FAN callouts to report faults to your fault management system and to initiate repair jobs.
Managing Planned Outages
For repairs, upgrades, and changes that require you to shut down the primary database, Oracle Restart provides interfaces that disable and enable services to minimize service disruption to application users. Using Oracle Data Guard Broker with Oracle Restart allows a coordinated failover of the database service from the primary to the standby for the duration of the planned outage. Once you complete the operation, you can return the service to normal operation.
The management policy for a service controls whether the service starts automatically when the database is restarted. If the management policy for a service is set to AUTOMATIC , then it restarts automatically. If the management policy for a service is set to MANUAL , then it must be started manually.
Fast Application Notification High Availability Events
Table 4-4 describes the FAN event record parameters and the event types, followed by name-value pairs for the event properties. The event type is always the first entry and the timestamp is always the last entry. In the following example, the name in the name-value pair is shown in Fan event type ( service_member ), and the value in the name-value pair is shown in Properties :
Table 4-4 Event Record Parameters and Descriptions
Version of the event record. Used to identify release changes.
SERVICE , SERVICE_MEMBER , DATABASE , INSTANCE , NODE , ASM , SRV_PRECONNECT . Note that database and Instance types provide the database service, such as DB_UNIQUE_NAME.DB_DOMAIN .
DATABASE UNIQUE NAME
The unique database supporting the service; matches the initialization parameter value for DB_UNIQUE_NAME , which defaults to the value of the initialization parameter DB_NAME .
The name of the instance that supports the service; matches the ORACLE_SID value.
The name of the node that supports the service or the node that has stopped; matches the node name known to Cluster Synchronization Services (CSS).
The service name; matches the service in DBA_SERVICES .
Values are UP , DOWN , NOT_RESTARTING , PRECONN_UP , PRECONN_DOWN , and UNKNOWN .
Data_Guard_Failover , Failure , Dependency , User , Autostart , Restart .
The number of service members that are currently active; included in all UP events.
The local time zone to use when ordering notification events.
A FAN record matches the database signature of each session as shown in Table 4-5.
Table 4-5 FAN Parameters and Matching Database Signatures
DATABASE UNIQUE NAME
Using Fast Application Notification Callouts
FAN callouts are server-side executables that Oracle Restart executes immediately when high availability events occur. You can use FAN callouts to automate the following activities when events occur, such as:
Opening fault tracking tickets
Sending messages to pagers
Starting and stopping server-side applications
Maintaining an uptime log by logging each event as it occurs
To use FAN callouts, place an executable in the directory grid_home/racg/usrco on both the primary and the standby database servers. If you are using scripts, then set the shell as the first line of the executable. The following is an example file for the grid_home/racg/usrco/callout.sh callout:
A FAN record matches the database signature of each session, as shown in Table 4-5. Use this information to take actions on sessions that match the FAN event data.
Table 4-4 for information about the callout and event details
Oracle Clients That Are Integrated with Fast Application Notification
Oracle has integrated FAN with many of the common Oracle client drivers that are used to connect to Oracle Restart databases. Therefore, the easiest way to use FAN is to use an integrated Oracle Client.
This chapter describes how to identify Oracle Database processes, and provides basic information about how to stop and restart them. It also describes how to set up automatic startup and shutdown of the Oracle Database. It contains the following sections:
When using Oracle Restart, you can use Service Control Utility (SRVCTL), a command-line interface, to manage Oracle processes (database instance, listener, Oracle ASM instance). With SRVCTL, you can manage the Oracle Restart configuration, see the status of processes managed by Oracle Restart, and start or stop processes such as Oracle Database. SRVCTL is enhanced to support Oracle Clusterware, and single instance Oracle databases with Oracle Restart.
Oracle Restart Integration with Oracle Data Guard
Oracle Restart is integrated with Oracle Data Guard (Data Guard) and the Oracle Data Guard Broker (the broker). When a database shutdown and restart is required in response to a role change request, Oracle Restart shuts down and restarts the database in an orderly fashion (taking dependencies into account), and according to the settings in the Oracle Restart configuration. Oracle Restart also ensures that, following a Data Guard role transition, all database services configured to run in the new database role are active and all services not configured to run in the new role are stopped.
In addition, the Oracle Restart configuration supports Data Guard–related configuration options for the following components:
Databases —When you add a database to the Oracle Restart configuration, you can specify the current Data Guard role for the database: PRIMARY , PHYSICAL_STANDBY , LOGICAL_STANDBY , or SNAPSHOT_STANDBY . If the role is later changed using the broker, Oracle Restart automatically updates the database configuration with the new role. If you change the database role without using the broker, you must manually modify the database's role in the Oracle Restart configuration to reflect the new role.
Database Services —When adding a database service to the Oracle Restart configuration, you can specify one or more Data Guard roles for the service. When this configuration option is present, upon database restart Oracle Restart starts the service only if one of the service roles matches the current database role.
Fast Application Notification with Oracle Restart
In a standalone server environment, Oracle Restart uses Oracle Notification Services (ONS) and Oracle Advanced Queues to publish Fast Application Notification (FAN) high availability events. Integrated Oracle clients use FAN to provide fast notification to clients when the service or instance goes down. The client can automate the failover of database connections between a primary database and a standby database.
This section describes how ONS and FAN work with Oracle Restart. It contains the following topics:
2.2 About Automating Database Shutdown and Startup
Oracle recommends that you configure the system to automatically start Oracle Database when the system starts, and to automatically shut it down when the system shuts down. Automating database startup and shutdown guards against incorrect database shutdown.
To automate database startup and shutdown, use the dbstart and dbshut scripts, which are located in the $ORACLE_HOME/bin directory. The scripts refer to the same entries in the oratab file, which are applied on the same set of databases. You cannot, for example, have the dbstart script automatically start sid1 , sid2 , and sid3 , and have the dbshut script shut down only sid1 . However, you can specify that the dbshut script shuts down a set of databases while the dbstart script is not used at all. To do this, include a dbshut entry in the system shutdown file, but do not include the dbstart entry in the system startup files.
The init command in the operating system documentation for more information about system startup and shutdown procedures
2.2.1 Automating Database Startup and Shutdown
To automate database startup and shutdown by using the dbstart and dbshut scripts:
- Log in as the root user.
- Edit the oratab file for the platform.
To open the file, use one of the following commands:
On Oracle Solaris:
On IBM AIX on POWER Systems (64-Bit) and Linux:
Database entries in the oratab file are displayed in the following format:
In this example, the values Y and N specify whether you want the scripts to start or shut down the database, respectively. For each database for which you want to automate shutdown and startup, first determine the instance identifier (SID) for that database, which is identified by the SID in the first field. Then, change the last field for each to Y .
You can set dbstart to autostart a single-instance database which uses an Automatic Storage Management installation auto-started by Oracle Clusterware. This is the default behavior for an Automatic Storage Management cluster. To do this, you must change the oratab entry of the database and the Automatic Storage Management installation to use a third field with the value W and N , respectively. These values specify that dbstart auto-starts the database only after the Automatic Storage Management instance is started.
If you add new database instances to the system and automate the startup for them, then you must edit the entries for those instances in the oratab file.
Linux and Oracle Solaris
IBM AIX on POWER Systems (64-Bit)
Change the value of the ORA_HOME environment variable to specify the Oracle home directory for the installation. Change the value of the ORA_OWNER environment variable to the user name of the owner of the database installed in the Oracle home directory (typically, oracle ).
This script can only stop Oracle Net listener for which a password has not been set. In addition, if the listener name is not the default name, LISTENER , then you must specify the listener name in the stop and start commands:
This chapter describes how to identify Oracle Database processes, and provides basic information about how to stop and restart them. It also describes how to set up automatic startup and shutdown of the Oracle Database. It contains the following sections:
When using Oracle Restart, you can use Service Control Utility (SRVCTL), a command-line interface, to manage Oracle processes (database instance, listener, Oracle ASM instance). With SRVCTL, you can manage the Oracle Restart configuration, see the status of processes managed by Oracle Restart, and start or stop processes such as Oracle Database. SRVCTL is enhanced to support Oracle Clusterware, and single instance Oracle databases with Oracle Restart.
The Basics of Oracle Restart and Oracle Standard Edition
In this blog post, we would like to discuss the basics of Oracle Restart when using it with Oracle Standard Edition in a standby database configuration.
Oracle Restart is integrated with Oracle Data Guard and the Data Guard broker, but this does not mean for those of you who use Standard Edition (which does not include Data Guard functionality) that you cannot get some value out of the use of Oracle Restart. My aim in this post is to show you a few basic steps to get you started with this utility.
Oracle Restart was introduced with Oracle 11gR2 and runs from the Grid Infrastructure (GI) home (software installation) when used in a non-clustered (single server) environment. You might have realized that when you install GI, configure ASM storage followed by the database software installation and database creation, that the database will automatically start at server startup. It is Oracle Restart that performs this little piece of magic around the auto starting of the database following a server restart, or in case of unexpected failure (crash).
There is a lot to Oracle Restart and there are a number of possibilities with it; but we'll only cover a few key points in this blog post, and so recommend you review the Oracle online documentation for more details, and as always TEST and TEST again before doing anything in production. The scripts and commands I use will also need to be adjusted to meet your environment particulars, but they should serve as a starting point for you to start playing with Oracle Restart. In my environment I am using the Oracle 11.2.0.3 software set (Grid Infrastructure and Database) running on Oracle Linux 5.7. ASM storage is configured and the database is called “prod” on both the primary and standby servers.
Oracle Restart takes dependencies into account and will attempt to start the components in the appropriate order. But be aware if you do not use the DBCA, for example, to create the database, and you use the manual “create database…” commands from the command line, the database will not be automatically added to Oracle Restart. You will have to manually add the database to Oracle Restart in this case. By using “DBCA” all required dependencies are put in place, such as ASM disk groups that need to be available before database start.
Oracle High Availability Services
It is also key to understand that Oracle Restart makes use of the Oracle High Availability Services - also known as HAS - to start and stop the components, so if the HAS services are not running, Oracle Restart will not work. To check if the HAS service is running in your environment you can execute the “crsctl check has” command as the GI owner and software home. Below is a summary of the key commands for the HAS services.
Check HAS Status:
Review if HAS is set to auto start:
Other commands that are useful include:
For more details on the crsctl command see the Oracle online documentation. Also note that the Oracle Restart configuration is stored in the Oracle Local Registry (OLR). We are not going to go into detail about the OLR, but you can check the status of this by running the following command from the GI home as the root user:
Adding a Database to Oracle Restart
Now let's have a quick look at one basic step - adding a database to Oracle Restart. The “srvctl” command line utility is used from the Oracle database software home, and for more details on the command you can use the “-h” option for help. Example:
In my environment, you will add the database “prod” to Oracle Restart using the “srvctl” command:
In the command above we specify the Oracle Home and spfile location, as well as the start (open) and shutdown (immediate) options to be used when the database is to be started or stopped.
To check the status of the database you can use the status option in the srvctl command, as below. In our environment the database was down and this is reflected in the status.
Configuration Parameters
The next step we want to show is the configuration parameters, which can be displayed using the config option of the srvctl command.
Now that the database is registered we can start it with the srvctl command:
See it in Action.
To show you the effect of using Oracle Restart, we are going to terminate the database in an “unexpected” way. Basically, we are going to kill the PMON background process. The effect is that Oracle Restart will automatically restart the database without us doing anything. So, an example:
The above is just a basic way to show how Oracle Restart will restart the database in case of unexpected behavior. Please note you can still use sqlplus to manually start/stop the database. Oracle Restart will not auto restart the database if you perform a shutdown from sqlplus. It will pick up that this is a controlled shutdown and will allow you to do so.
If your database listener is not already added to Oracle Restart, you can easily add it following similar steps using the “srvctl add listener” command. One of the advantages you have now is that during server restart the database will be started automatically.
Now for the Standby
In the next section what we would like to focus on is the standby database. Now in my test environment we are using the same setup on the standby server as the primary, which means the standby database also makes use of ASM storage, and Grid Infrastructure is already installed - so this means Oracle Restart is available to use. Now remember, we are using Standard Edition and so do not have the Data Guard option and the integration options it has with Oracle Restart.
There are a few ways of approaching this; first you can add the standby database to Oracle Restart, but the key is to make sure it starts it in a mounted state, not open. Otherwise what will happen is your standby database will be auto started to an open Read-Only state. In summary you want the physical standby to start automatically (in case of unexpected failure or server restart) into the correct state ready to perform recovery, which is a mounted state.
To perform this you can add the standby database as follows:
The Database is now added and configured to auto start but into a “mounted” state. To review the configuration you can use the “srvctl config” option:
The next step is to start the standby database using the srvctl command. In our case the standby database was shutdown when we added it to Oracle Restart, so first thing to do is a status check followed by starting the database and then reviewing the database open mode and role.
We can now stop and start the standby database using the srvctl command and due to the configuration stating that this database should be started into a mount state, it will always auto start the database into a mount state.
Now remember we are using Standard Edition without Data Guard integration. When using Data Guard and the Data Guard broker, the Oracle Restart configuration will automatically be updated during Switchover or Failover. This means the database role and start mode can be specified (-r PHYSICAL_STANDBY|PRIMARY option and –s open|mount) when you add it to Oracle Restart, and if a switchover is executed Data Guard will update these values to reflect the switch. For example, when using Data Guard on the primary node you would specify:
You then perform a switchover between the two nodes. Data Guard will update the Oracle Restart values so that the “prod” database will have its configuration changed to “-r PHYSICAL_STANDBY –s mount” and the “proddr” Oracle Restart configuration will be updated to reflect that it is now a primary – “-r PRIMARY –s open”.
But when using Standard Edition this option is not possible, so how do we achieve this? Well there are two ways we will go through:
Option 1
Following a Graceful Switchover (role switch) or Activation (failover) you have to run a manual update command on each node to update its startup value from “mount” to “open” on the original standby – and on the original primary to reflect that it is now a standby you have to update the startup value from “open” to “mount”. For example:
This is a bit of a manual process, but it can easily be scripted, and then executed at the end of a role switch or activation.
Option 2
The second option is a bit more complex, however, it is possible to automate the correct startup using a local custom resource, which can be added to Oracle Restart. Please note that this option is a lot more complex and it is recommended that you have a good understanding of adding resources, dependencies and action scripts. There is, as in most cases more than one way to do it and maybe the commands and scripts provided below can help you get started or you might just want to keep it simple and use the option 1 mentioned above. These scripts and commands are for reference only and you will need to TEST and adjust for your own environment.
The process can be summarized as follows:
Each database (primary and standby) is always started in a mounted state by Oracle Restart.
A resource - “action” script is executed that will interrogate the database to review the controlfile type and database open mode. If the database is using a primary controlfile, the script executes the command to open the database read/write. If the script finds that the database makes use of a standby controlfile, the script will exit without doing anything, as the database would be in a mounted state, which is what we want for the standby. This way we can control the correct database startup mode while still using Oracle Restart with a standard edition standby environment.
The first step is creating a resource action script. Now for more details on how this works, and examples, please review the Oracle Clusterware Administration and Deployment Guide with specific reference to these two sections:
In my test case I saved the script in =/u01/app/grid/admin/action_script/startdb and made sure it has user (Grid Infrastructure owner) execute permissions (chmod u+x startdb).
The next step then is to create the resource. This is done as the Grid Infrastructure owner by executing the following command:
Using the crsctl add resource command I am adding a custom resource called “custom.restardb” which will be executing the action script created. A dependency is set on the prod database (resource name “ora.prod.db”) so this resource (custom.restartdb) will only start if the database prod resource is either online or in an intermediate state (resource is partially online) - such as a database that is in a mounted state.
Example output in the log file on the primary node:
Example output in the log file on the standby node:
The action script will review the database status when executing, if the database is a primary database with a primary (current) controlfile, the action script will open the database. If it is a standby database (standby controlfile) it will leave the database in a mounted state.
Using the above example, if the server is unexpectedly restarted, the databases will be started in the correct state. Again please note that this is just an example to show some of the possibilities.
In summary, Oracle Restart is a powerful option you can use, and in most cases (99% of the time) our recommendation is to KEEP IT SIMPLE - and maybe just add an additional step at the end of your Graceful Switchover or Activation to manually update the startup parameter for the database (Option 1 above) in Oracle Restart (srvctl modify database –d -s open|mount). But if you feel more adventurous and don't mind a little complexity, hopefully, the section above with the action script will give you an idea of where to start. For more examples please see the Oracle online documentation.
Oracle Restart Configuration
Oracle Restart maintains a list of all the Oracle components that it manages, and maintains configuration information for each component. All of this information is collectively known as the Oracle Restart configuration . When Oracle Restart starts a component, it starts the component according to the configuration information for that component. For example, the Oracle Restart configuration includes the location of the server parameter file (SPFILE) for databases, and the TCP port to listen on for listeners.
If you install Oracle Restart and then create your database with Database Configuration Assistant (DBCA), DBCA automatically adds the database to the Oracle Restart configuration. When DBCA then starts the database, the required dependencies between the database and other components (for example disk groups in which the database stores data) are established, and Oracle Restart begins to manage the database.
You can manually add and remove components from the Oracle Restart configuration with SRVCTL commands. For example, if you install Oracle Restart onto a host on which a database is already running, you can use SRVCTL to add that database to the Oracle Restart configuration. When you manually add a component to the Oracle Restart configuration and then start it with SRVCTL, Oracle Restart begins to manage the component, restarting it when required.
Adding a component to the Oracle Restart configuration is also referred to as "registering a component with Oracle Restart."
Other SRVCTL commands enable you to view the status and configuration of Oracle Restart–managed components, temporarily disable and then reenable management for components, and more.
When Oracle Restart is installed, many operations that create Oracle components automatically add the components to the Oracle Restart configuration. Table 4-2 lists some create operations and whether or not the created component is automatically added.
Table 4-2 Create Operations and the Oracle Restart Configuration
Create a database with OUI or DBCA
Create a database with the CREATE DATABASE SQL statement
Create an Oracle ASM instance with OUI, DBCA, or ASMCA
Create a disk group (any method)
Add a listener with NETCA
Create a database service with SRVCTL
Create a database service by modifying the SERVICE_NAMES initialization parameter Foot 1
Create a database service with DBMS_SERVICE.CREATE_SERVICE
Create a standby database
Footnote 1 Not recommended when Oracle Restart is in use
Table 4-3 lists some delete/drop/remove operations and whether or not the deleted component is also automatically removed from the Oracle Restart configuration.
Table 4-3 Delete/Drop/Remove Operations and the Oracle Restart Configuration
Delete a database with DBCA
Delete a database by removing database files with operating system commands Foot 1
Delete a listener with NETCA
Drop an Oracle ASM disk group (any method)
Delete a database service with SRVCTL
Delete a database service by any other means
Footnote 1 Not recommended
2.1 Stopping and Starting Oracle Processes
This section describes how to stop and start Oracle processes. It contains the following topics:
2.1.1 Stopping and Starting Oracle Database and Oracle Automatic Storage Management Instances
This section describes how to stop and start Oracle Database and Oracle Automatic Storage Management instances and contains the following topics:
2.1.1.1 Stopping an Oracle Database or Oracle Automatic Storage Management Instance
Do not stop an Oracle Automatic Storage Management instance until you have stopped all Oracle Database instances that use Oracle Automatic Storage Management instance to manage their storage.
To stop an Oracle Database or Oracle Automatic Storage Management instance:
- Run the following commands to identify the SID and Oracle home directory for the instance that must be shut down:
On Oracle Solaris:
On other operating systems:
The oratab file contains lines similar to the following, which identify the SID and corresponding Oracle home directory for each database or Oracle Automatic Storage Management instance on the system:
Oracle recommends that you use the plus sign (+) as the first character in the SID of Oracle Automatic Storage Management instances.
Bourne, Bash, or Korn shell:
When prompted, specify the SID for the instance.
After the instance shuts down, you can quit SQL*Plus.
2.1.1.2 Restarting an Oracle Database or Oracle Automatic Storage Management Instance
If the database instance uses Oracle Automatic Storage Management for storage management, then you must start the Oracle Automatic Storage Management instance before you start the database instance.
To restart an Oracle Database or Oracle Automatic Storage Management instance:
- Repeat steps 1 and 2, if required, to set the ORACLE_SID and ORACLE_HOME environment variables to identify the SID and Oracle home directory for the instance you want to start.
- Run the following commands to start the instance:
After the instance starts, you can exit from SQL*Plus.
2.1.2 Stopping and Starting Oracle Restart
To stop or start Oracle Restart, run the following command:
Start: This option is used to start Oracle Restart
Syntax and Options:
Stop: This option is used to stop Oracle Restart
Syntax and Options:
Oracle Database Administrator's Guide for more information about the srvctl commands
Читайте также:
- Есть ли звуковая карта в наушниках
- Поколения операционных систем назначение состав и функции ос понятие компьютерных ресурсов
- Ниссан альмера классик бортовой компьютер вместо часов
- Объем видеопамяти равен 2 мб разрешающая способность дисплея 800 600 сколько оттенков серого
- Чем открыть файл dbf foxpro