So shut down the Oracle 10g database cluster.

Sometimes we need to go to the customer site to do support, occasionally need to stop the database cluster, and then downtime. We usually take a more prudent approach rather than a savage and violent approach.

In a barbaric way

# / u01/app/oracle/product/10.2.0/db_1/bin/crsctl stop crs

Journal

Shutting down instance (abort)

License high water mark = 5

Instance terminated by USER, pid = 9068

two。 In a gentle way

[root@node1 root] # su-oracle

[oracle@node1] $crs_stat-t-v

[oracle@node1 ~] $srvctl config database

Racdb

[oracle@node1] $srvctl stop database-d racdb

[oracle@node1] $srvctl stop asm-n node1

[oracle@node1] $srvctl stop asm-n node2

[oracle@node1] $srvctl stop nodeapps-n node1

[oracle@node1] $srvctl stop nodeapps-n node2

[root@node1 root] # / u01/app/oracle/product/10.2.0/db_1/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.

[root@node1 root] # shutdown-h 0

Broadcast message from root (pts/1) (Thu Jul 20 09:16:28 2017):

The system is going down for system halt NOW!

3. Startup method

[root@node1 ~] # su-oracle

[oracle@node1 ~] $which crsctl

/ u01/app/oracle/product/10.2.0/db_1/bin/crsctl

[oracle@node1 ~] $exit

Logout

[root@node1 ~] # / u01/app/oracle/product/10.2.0/db_1/bin/crsctl start crs

Attempting to start CRS stack

The CRS stack will be started shortly

Recently a little busy, some slack, the blog update is not timely. We should continue to stick to it, make fewer excuses and criticize ourselves.