8 Replies Latest reply: Nov 3, 2012 9:06 AM by user569151 RSS

    Best practice for RAC planned downtime maintenance?

    user569151
      I have a 3 node RAC on Linux redhat. DB version is 11gr2.

      I want to know the steps to perform each node OS patch upgrade.

      I want to be sure I did right steps:
      1). Node 1, stop crs and do the OS patch upgrade.
      2). same steps for Node 2, 3.

      Is this right?

      Thank you for any help.
        • 1. Re: Best practice for RAC planned downtime maintenance?
          P.Forstmann
          Yes this is right. Please read "Operating System Upgrades and Hardware Upgrades" section in High Availability Overview: http://docs.oracle.com/cd/E11882_01/server.112/e17157/planned.htm#HAOVW151.
          • 2. Re: Best practice for RAC planned downtime maintenance?
            user569151
            Thank you.

            My concern is here, let's say each node has to be restarted.

            So my procedure should be on 1st node: crsctl stop crs to stop everything and failover everything to other nodes.

            I wonder crsctl stop crs will cause ASM instance to be down?
            • 3. Re: Best practice for RAC planned downtime maintenance?
              Satishbabu Gunukula
              please refer below link for steps

              http://docs.oracle.com/cd/B28359_01/install.111/b28264/procstop.htm
              http://www.oracleracexpert.com/2012/01/how-to-stop-and-start-processes-in.html

              hope this helps

              regards,
              http://www.oracleracexpert.com
              Manage Access Control List in Oracle 11g and ORA-24247
              http://www.oracleracexpert.com/2012/09/manage-access-control-list-in-oracle.html
              Convert Single Instance to RAC – Part1: Duplicate DB using RMAN
              http://www.oracleracexpert.com/2012/10/convert-single-instance-to-rac-part1.html
              • 4. Re: Best practice for RAC planned downtime maintenance?
                Levi Pereira
                user569151 wrote:
                I have a 3 node RAC on Linux redhat. DB version is 11gr2.

                I want to know the steps to perform each node OS patch upgrade.

                I want to be sure I did right steps:
                1). Node 1, stop crs and do the OS patch upgrade.
                2). same steps for Node 2, 3.
                If your RAC environment is configured properly follow this step:

                Node 1:
                * Relocate services to node 2 or 3 and stop database instance and service using SRVCTL
                * Stop Clusterware using CRSCTL
                * Disable automatic Startup of Clusterware on this node using CRSCTL
                * Patch your OS
                * Relink Oracle Binaries (Grid Infrastructure/Oracle Database) (P.S You will need unlock and re-lock your Grid Home to relink binaries see note RAC: Frequently Asked Questions [ID 220970.1])
                If you are using ACFS you must check if that OS Upgrade will affect ACFS drivers (ACFS Supported On OS Platforms. [ID 1369107.1])
                * Enable Automatic Startup of Clusterware on this node using CRSCTL
                * Start Clusterware using CRSCTL
                * Start Database and Services with SRVCTL

                Repeat steps above on Node 2 and 3

                Of course don't forget a good plan to backup and recovery to support case of failure.

                http://docs.oracle.com/cd/E11882_01/server.112/e17157/planned.htm#CJACDIJD

                Is It Necessary To Relink Oracle Following OS Upgrade? [ID 444595.1]

                My concern is here, let's say each node has to be restarted.

                So my procedure should be on 1st node: crsctl stop crs to stop everything and failover everything to other nodes.

                I wonder crsctl stop crs will cause ASM instance to be down?
                Yes "CRSCTL STOP CRS" will try stop all clusterware resource with clean state. If any problem occurs will be raised on your prompt.




                Regards,
                Levi Pereira

                Edited by: Levi Pereira on Nov 1, 2012 7:35 PM
                • 5. Re: Best practice for RAC planned downtime maintenance?
                  user569151
                  our rac system is configured with transparent client failover. So service name is created per Oracle MAA document.

                  If so do I still have to relocate the service before maintenance?

                  If node 1 down without service relocation, will other node still get the connection? since service name is created for all three node rdbms.

                  Thanks
                  • 6. Re: Best practice for RAC planned downtime maintenance?
                    Levi Pereira
                    user569151 wrote:
                    our rac system is configured with transparent client failover. So service name is created per Oracle MAA document.

                    If so do I still have to relocate the service before maintenance?

                    If node 1 down without service relocation, will other node still get the connection? since service name is created for all three node rdbms.
                    Yes. The RAC is designed to do it without relocate service manually because he do it automatically keeping all connection alive since you have one node active.

                    You ask for best practice on planned maitenance, so the best practice is relocate service/stop database manually ... and so on.

                    See docs:
                    http://docs.oracle.com/cd/E11882_01/rac.112/e16795/hafeats.htm#RACAD7029
                    • 7. Re: Best practice for RAC planned downtime maintenance?
                      user569151
                      Then after maintenance how do i relocate service to previous state?
                      The service is for all intances.
                      • 8. Re: Best practice for RAC planned downtime maintenance?
                        user569151
                        Here is our service config info:

                        srvctl config service -d prd
                        Service name: prd_rw_service
                        Service is enabled
                        Server pool: prd_prd_rw_service
                        Cardinality: 2
                        Disconnect: false
                        Service role: PRIMARY
                        Management policy: AUTOMATIC
                        DTP transaction: false
                        AQ HA notifications: true
                        Failover type: SELECT
                        Failover method: BASIC
                        TAF failover retries: 150
                        TAF failover delay: 10
                        Connection Load Balancing Goal: LONG
                        Runtime Load Balancing Goal: NONE
                        TAF policy specification: NONE
                        Edition:
                        Preferred instances: prd1,prd2
                        Available instances: