Shulou(Shulou.com)06/01 Report--

1. Process description 1.1. Purpose of process writing

In order to cooperate with application changes, host maintenance, abnormal downtime and restart, it is necessary to restart the database, restart ORACLE cluster software, and hosts. In order to ensure the standardization of database start and stop operation, the operation specification is customized.

The specification is only for databases and cluster environments using ORACLE cluster software. Host clusters, cluster file systems, host restart and other specifications are provided by other application maintenance manufacturers.

1.2. Related personnel 1.2.1. Database and application responsible person's information

Database name

Database person in charge

Contact information

Person in charge of business

Contact information

ZWDB

1.2.2. Process related personnel information

Company

Contact person

Contact information

Emergency contact

Contact information

Business support room

1.3. The operation flow is 1.4. Action prompt

$is the operating system command line prompt, indicating that the operation command is an ordinary user operating system command.

# is the action user root user prompt, indicating that the operation command is performed by the root user.

SQL > is the SQL command prompt, indicating that the operation command is a SQL command.

two。 Stop database operations (oracle)

The following actions, unless otherwise specified, are performed by oracle users. Before stopping listening, stopping instances, kill user processes and database processes, be sure to get confirmation from users and managers to prevent failures caused by misoperation.

2.1. Confirm the current login host environment

Confirm that the current login host is the same as the operation host.

$hostname

2.2. Confirm operation of database SID

$echo $ORACLE_SID

2.3. Stop database related applications

This operation is done by the application manufacturer, and the database checks to see if the number of processes of type USER has been reduced.

SQL > SELECT INST_ID, COUNT (1) FROM GV$SESSION WHERE TYPE = 'USER' GROUP BY INST_ID

If there are still a large number of user-type processes, check the process name and host information and inform the application manufacturer to deal with it.

SQL > SET LINESIZE 120

SQL > COL MACHINE FOR A30

SQL > SELECT INST_ID, PROGRAM, MACHINE, COUNT (1) FROM GV$SESSION WHERE TYPE = 'USER' GROUP BY INST_ID, PROGRAM, MACHINE ORDER BY 4

2.4. Stop database monitoring 2.4.1. Non-cluster environment

In a non-clustered environment, the default listening name of the database is LISTENER. You can query the name of the currently running database listening with the following command:

$ps-ef | grep tns

/ oracle/app/oracle/product/10.2.0/db/bin/tnslsnr LISTENER_RAC10G1-inherit

The blue part is the name of the database listening, and the non-standard listening name, which can be turned off with the following command:

$lsnrctl stop LISTENER_RAC10G1

Pass through

$ps-ef | grep tns

The command checks to see if the monitor is turned off properly.

If the listening cannot be turned off properly, you can also use kill-9 to kill the listening process.

2.4.2. Cluster environment

In a cluster environment, you can turn off listening by using regular lsnrctl commands, or by using srvctl commands or crs commands. However, it is recommended to use the srvctl command for resource management operations.

For the stop listening operation in the cluster environment, the operation of the corresponding host is carried out according to the requirement of stopping the library.

a. Query the running status of monitoring in the cluster

$crs_stat-t | grep lsnr

Ora....G1.lsnr application ONLINE ONLINE rac10g1

Ora....G2.lsnr application ONLINE ONLINE rac10g2

b. Stop node snooping

Stop the listener of the corresponding database host as needed

$srvctl stop listener-n rac10g1

c. Stop SCAN_LISTENER (11g)

The concept of SCAN_LISTENER is introduced in ORACLE 11G, so if you need to stop all instances of the 11g cluster, you need to stop SCAN_LISTENER.

$srvctl stop scan_listener

d. Query the running status of monitoring in the cluster

Make sure that the listening of the operation node is stopped.

$crs_stat-t | grep lsnr

Ora....G1.lsnr application OFFLINE OFFLINE

Ora....G2.lsnr application ONLINE ONLINE rac10g2

Other ways to stop listening:

a. Stop listening through the lsnrctl command, which needs to be done on all nodes in the cluster

$ps-ef | grep tns

/ oracle/app/oracle/product/10.2.0/db/bin/tnslsnr LISTENER_RAC10G1-inherit

$lsnrctl stop LISTENER_RAC10G1

b. Stop listening through the crs_stop command

$crs_stat | grep lsnr

NAME=ora.rac10g1.LISTENER_RAC10G1.lsnr

NAME=ora.rac10g2.LISTENER_RAC10G2.lsnr

$crs_stop

Usage: crs_stop resource_name [...] [- f] [- Q] ["attrib=value..."]

Crs_stop-c cluster_member [...] [- Q] ["attrib=value..."]

Crs_stop-all [- Q]

The parameter used by this command is the cluster resource, so the parameter is the whole value corresponding to the NAME statement.

$crs_stop ora.rac10g1.LISTENER_RAC10G1.lsnr

2.5. Check the application connection

Check the non-local session connection of the database, which needs to be performed by all nodes, and you need to pay attention to the users who are running the process:

$ps-ef | grep "LOCAL=NO"

If there are a large number of processes, indicating that there are still a large number of application processes that have not been stopped, check with the following command:

SQL > SET LINESIZE 120

SQL > COL MACHINE FOR A30

SQL > SELECT INST_ID, PROGRAM, MACHINE, COUNT (1) FROM GV$SESSION WHERE TYPE = 'USER' GROUP BY INST_ID, PROGRAM, MACHINE ORDER BY 4

You can kill non-local connections by using kill-9 (this operation can only be confirmed by the application manufacturer):

$hostname

$id

$ps-ef | grep "LOCAL=NO" | awk'{print $2}'| xargs kill-9

Note: in the version of ORACLE11G, because the listener runs under the grid user, the process belonging to the LOCAL=NO group may be the grid user. It needs to be confirmed before it is needed.

2.6. Perform log switching

In order to ensure that during the database shutdown, all dirty data is written to disk and the logs are archived. It is recommended that you perform log switching and checkpointing operations before performing a database shutdown operation.

Write dirty data from all nodes in the cluster to the data file:

SQL > alter system checkpoint global

The global parameter is for cluster databases and is not required for single instance databases.

Log switching is performed for all instances in the cluster. It is recommended to perform the log switching operation multiple times:

SQL > alter system archive log current

In non-archive mode, the command does not execute properly and can be executed on each node:

SQL > alter system switch logfile

Command to replace.

Perform the checkpoint operation again:

SQL > alter system checkpoint global

Make sure that when stopping the library, the log of ACTIVE status is less than group 1:

SQL > SELECT INST_ID, GROUP#, STATUS, ARCHIVED FROM GV$LOG WHERE STATUS IN ('ACTIVE',' CURRENT')

Ensure that the MTTR time is within an acceptable range (abnormal database shutdown, recovery time after startup):

SQL > SET LINESIZE 120

SQL > SELECT RECOVERY_ESTIMATED_IOS,ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,LOG_FILE_SIZE_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR FROM GV$INSTANCE_RECOVERY

2.7. Stop the database 2.7.1. Non-cluster environment

The database is closed by immediate.

SQL > shutdown immediate

2.7.2. Cluster environment

Pause instance

In the case of stopping some instances, you need to stop the specified database instance by stopping the instance.

$hostname

$id

$ps-ef | grep ora_smon

$srvctl stop instance-d-I

Pause database

Shut down the database through the srvctl command:

$crs_stat | grep db$

NAME=ora.crmdb.db

$srvctl stop database-d crmdb

Use the crs_stat command to check whether the database is closed properly. Inst and db resources are the corresponding instance and database resources:

$crs_stat-t

Name Type Target State Host

Ora....b1.inst application OFFLINE OFFLINE

Ora....b2.inst application OFFLINE OFFLINE

Ora.crmdb.db application OFFLINE OFFLINE

Note: in the 11G version of ORACLE, instance information is no longer available in the crs resource.

2.7.3. Perform abort operation

Note that this operation may cause damage to the database, and this operation is not recommended in non-special cases.

If the database cannot be shut down normally by the above steps, you can abort the database by aborting the PMON process or shutdown abort. After all the core processes of the database instance are shut down, check whether the shared memory segment of the operating system has been released. Do not restart the database until the shared memory segment is freed.

SQL > shutdown abort

$ipcs-m | grep oracle

0x61a4a848 3047431 oracle 640 132120576 14

If there is still shared memory information for oracle in the returned result, indicating that the database is not completely stopped, check to see if there are still legacy processes, or wait for shared memory resources to be released.

After performing the abort operation, be sure to perform a normal database start and stop operation to prevent data corruption caused by abnormal operations.

SQL > startup

SQL > shutdown immediate

2.8. Stop database cluster (root)

Stopping the database cluster requires the use of root users. This operation needs to be done on all nodes in the cluster.

Before performing this operation, you need to check that the database is stopped properly:

$crs_stat-t

Ensure that the status of the resource ending in inst/db in the resource is already OFFLINE. If the status is ONLINE, follow the previous steps to stop the database.

To stop the cluster, you need to process under the bin directory of CRS_HOME (10g) / GRID_HOME (11g):

# cd / oracle/app/oracle/product/10.2.0/crs/bin

#. / crsctl stop crs

Stopping resources. This could take several minutes.

Successfully stopped CRS resources.

Stopping CSSD.

Shutting down CSS daemon.

Shutdown request successfully issued.

Check the shutdown results:

# crsctl check crs

Failure 1 contacting CSS daemon

Cannot communicate with CRS

Cannot communicate with EVM

Make sure that the command does not return a result:

# ps-ef | grep oracle | grep d.bin

2.9. Example of an action script

Take CRMDB as an example:

2.9.1. Confirm database and host information

$hostname

SQL > show parameter instance

2.9.2. Check the application process information

SQL > SELECT INST_ID, PROGRAM, MACHINE, COUNT (1) FROM GV$SESSION WHERE TYPE = 'USER' GROUP BY INST_ID, PROGRAM, MACHINE ORDER BY 4

2.9.3. Stop database monitoring

$crs_stat | grep lsnr

$srvctl stop listener-n crmdb1-l LISTENER_CRMDB1

$srvctl stop listener-n crmdb2-l LISTENER_CRMDB2

$srvctl stop listener-n crmdb3-l LISTENER_CRMDB3

2.9.4. Kill a non-local connection process

$ps-ef | grep "LOCAL=NO" | awk'{print $2}'| xargs kill-9

2.9.5. Toggle database log

SQL > alter system checkpoint global

SQL > alter system archive log current

SQL > alter system archive log current

SQL > alter system archive log current

SQL > alter system archive log current

SQL > alter system archive log current

SQL > alter system archive log current

SQL > alter system checkpoint global

2.9.6. Stop the database

$crs_stat | grep db$

$srvctl stop database-d crmdb

2.9.7. Stop clustering

# crsctl start crs

3. Start a database operation

The following actions, unless otherwise specified, are performed by oracle users. Normally, in the cluster startup meeting, all related resources will be started automatically. However, there may be special circumstances, such as setting the resource startup status to disable or manually stopping the cluster without restarting the host, so you need to start the resource manually.

3.1. Start the database cluster

The root user is required to start the database cluster. This operation needs to be done on all nodes in the cluster.

The command needs to be executed in the bin directory:

# cd / oracle/app/oracle/product/10.2.0/crs/bin

[root@rac10g1 bin] #

[root@rac10g1 bin] # crsctl start crs

Attempting to start CRS stack

The CRS stack will be started shortly

This process may take a long time, and can be tracked by monitoring cluster-related events and crs logs:

[root@rac10g1 bin] # ps-ef | grep d.bin

[root@rac10g1 bin] # cd.. / log/rac10g1/crsd/

[root@rac10g1 crsd] # tail-f crsd.log

After the cluster starts successfully, you can view the cluster status through the crs_stat command:

# crs_stat-t

Name Type Target State Host

Ora....0g1.gsd application ONLINE ONLINE rac10g1

Ora....0g1.ons application ONLINE ONLINE rac10g1

Ora....0g1.vip application ONLINE ONLINE rac10g1

After the cluster starts successfully, make sure that the gsd/ons/vip process in the cluster resource has the status of ONLINE and is running on its own node.

3.2. Start database snooping 3.2.1. Non-cluster environment

In a non-clustered environment, the default listening name of the database is LISTENER. You can view the listening name through the listener.ora configuration file:

$cd $ORACLE_HOME/network/admin

[oracle@rac10g1 admin] $

$cat listener.ora

LISTENER_RAC10G1 =

(DESCRIPTION_LIST =.

)

Start snooping through the lsnrctl start command:

$lsnrctl start LISTENER_RAC10G1

Check the running status of the monitor through the lsnrctl status command:

$lsnrctl status LISTENER_RAC10G1

3.2.2. Cluster environment

In a cluster environment, you can start monitoring through the srvctl command.

Query the name of the listener in the cluster:

$crs_stat | grep lsnr

NAME=ora.rac10g1.LISTENER_RAC10G1.lsnr

NAME=ora.rac10g2.LISTENER_RAC10G2.lsnr

Execute the srvctl command

$srvctl start listener-h

Usage: srvctl start listener-n [- l]

-n Node name

-l "" Comma separated listener names

-h Print usage

$srvctl stop listener-n rac10g1-l LISTENER_RAC10G1

3.3. Start database 3.3.1. Non-cluster environment

Through open, which is the default method of startup, database startup operation is performed:

SQL > startup

3.3.2. Cluster environment

Start the database through the srvctl command:

$srvctl start database-d crmdb

Check the alert logs of each node and track the database shutdown process:

$cd $ORACLE_BASE/admin/$ {DB_NAME} / bdump

$tail-f alert_crmdb1.log

The ${DB_NAME} parameter is the database name.

Check whether the database is started normally through the crs_stat command. Inst and db resources are the corresponding instance and database resources:

$crs_stat-t

Name Type Target State Host

Ora....b1.inst application ONLINE ONLINE rac10g1

Ora....b2.inst application ONLINE ONLINE rac10g2

Ora.crmdb.db application ONLINE ONLINE rac10g2

3.3.3. Running status check

Ensure that the running status of each instance is OPEN:

SQL > ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS'

SQL > SELECT INST_ID, STARTUP_TIME, STATUS FROM GV$INSTANCE ORDER BY INST_ID

3.4. Start the database service

View all the service configured in the database at that time

$srvctl config service-d crmdb

Srvcrmdb1 PREF: crmdb1 AVAIL: crmdb2

Srvcrmdb2 PREF: crmdb2 AVAIL: crmdb1

Start service with the srvctl command:

$srvctl start service-d crmdb-s srvcrmdb1

$srvctl start service-d crmdb-s srvcrmdb2

View the running status of service:

$srvctl status service-d crmdb

Service srvcrmdb1 is running on instance (s) crmdb1

Service srvcrmdb2 is running on instance (s) crmdb2

3.5. Test the database connection

Use the vip address and scan (11g) address to test the remote login of the database to ensure that all instances can log in successfully.

$sqlplus system/password@rac10g1-vip:1521/crmdb

$sqlplus system/password@rac10g2-vip:1521/crmdb

$sqlplus system/password@scan_ip:1521/crmdb

3.6. Conduct application connection testing

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.