5 Replies Latest reply: Sep 20, 2011 6:31 PM by 888310 RSS

    Upgrade to PT 8.51 - What steps need attention due to a RAC database?

    user3242117
      I'm upgrading Peopletools from 8.48.10 to 8.51.11, at the same time as the database layer was changed to a RAC, multi-node database.

      As I run through the upgrade steps, I've hit some steps that required special attention.

      The REL### scripts are are an example.

      The REL849nDBTSFIX.SQL had tablespace names like "PSINDEX", not the new RAC ones - requiring updates to run.
      The REL850nDBTSFIX.SQL and the REL851nDBTSFIX.SQL had a mixture of the old "PSINDEX" names and the new RAC ones,
      including some of the new RAC ones that were truncated so that the syntax was wrong.


      Has anyone run through this process and can provide some pointers as to what steps to watch out for?

      Any workarounds that streamline the CA steps would be greatly appreciated.


      Cheers
        • 1. Re: Upgrade to PT 8.51 - What steps need attention due to a RAC database?
          888310
          I follow this as a thumb rule..

          I keep only one node up (in case of RAC) while running through the upgrade steps.


          RELDBTSFIX is a custom generated script. So if you thin the script is not correct according to you DB setup, then you can generate the script again with the step DBTSFIX report in CA.

          Still if you think the tablespace names are not reflected correctly, you can edit the script to point it to any custom tablespace.

          BTW - i didn't quite get your point - "old "PSINDEX" names and the new RAC ones" . I am assuming that old PSINDEX name refers to delivered peoplesoft tablespace names and RAC ones refers to custom table space names.


          There are new tables in 8.51 whilch the rel script will map to delivered tablespaces. Edit the script if you want them to be mapped to your custome tablespace.



          Regards
          Nevin
          • 2. Re: Upgrade to PT 8.51 - What steps need attention due to a RAC database?
            user3242117
            Re: Rule of thumb is one node up

            I'll check with the DBAs but I believe they have allocated one of the three RAC nodes to CRM and one to FDM. The baseline processing time seems to be within what I'd expect (12 hours for CRM and 18 hours for FDM).



            Re: RELDBTSFIX is a custom generated script. So if you think the script is not correct ...

            For the rel script tablespace names, the generated by CA names don't match the RAC database.

            One example is the delivered tablespace name for indexes - PSINDEX. CA generates the script using PSINDEX where our custom tablespace name for indexes is {envname}_index, where an possible custom name would be CRMDM_INDEX.

            I had to manually edit REL850nDBTSFIX.SQL for this change, as well as PTTBL, PTAMSG, PSIMAGE etc. etc - which is time consuming.


            And yes - you are correct, when I say "old", I mean the delivered tablespace names instead of the new ones setup in the RAC database.


            So I'm hoping for two things.

            a) Someone who has done similar can provide pointers of the steps that will need updates/tweks/special attention.

            b) Ideally - if there is an update that can be done early in the upgrade to tweak what the scripts generate instead of having to manually update them, this would be helpful.



            Cheers

            Edited by: user3242117 on Sep 15, 2011 11:03 AM
            • 3. Re: Upgrade to PT 8.51 - What steps need attention due to a RAC database?
              888310
              For any table which already exists in the database, if the CA ( i would rather say DBTSFIX.sqr) generates the script with a tablespace different from the actual table to tablespace mapping, then there is something going wrong.
              Are you sure that the step Running a DBTSFIX report completed successfully ??
              This sqr modifies the original REL script to preserve your existing table to table space mapping, this script is what you get as the CA generated script.
              This hold true for indexes as well.

              And... for any new table introduced in the new tools release, the tablespace mapping will be as per peoplesoft standards. If you want these tables to be mapped to your custom tablespaces, there is no shortcut, atleast for the first time... You have to edit the scripts manually.
              Only optimization you can do is reusing the script in subsequent test passes or Move To Prod pass.

              Regards
              Nevin
              • 4. Re: Upgrade to PT 8.51 - What steps need attention due to a RAC database?
                user3242117
                Re: CA ( i would rather say DBTSFIX.sqr) generates the script with a tablespace different from the actual table to tablespace mapping, then there is something going wrong.

                Hmmm ... the next step in the template is "Editing the DBTSFIX Output Scripts". Included in the docs is that the edits should "Verify that the data definition language (DDL) is accurate for your environment for tablespaces, database names, owner IDs, etc.", which implies a mismatch is possble.

                IAC, CA reports that DBTSFIX ran successfully, the log says it ran successfully and the expected scripts are produced for the interim levels (i.e. 849, 850 and 851). So without some sort of direction, it seems my options are to re-use corrected scripts or trace the DBTSFIX.sqr to figure out where it is pulling the tablespace names from.

                Note that I tried correcting the entries in PSRECTBLSPC before running the upgrade - which has helped for some scripts but not the RELxxxDBTSFIX.sql ones.


                Re: And... for any new table introduced in the new tools release, the tablespace mapping will be as per peoplesoft standards.

                So if the REL script adds a new table/index, the delivered tablespace names will be on them where a modification should have the RAC database tablespace name, correct?

                I'm also expecting that the projects loaded from file will also ahve the delivered tablespace names on new objects.


                Cheers

                Edited by: user3242117 on Sep 20, 2011 9:54 AM
                • 5. Re: Upgrade to PT 8.51 - What steps need attention due to a RAC database?
                  888310
                  Out of curiosity, I tried out your scenario in my test environment (but it was not RAC anyway).
                  Here is what I did

                  1. picked up table X from the rel script
                  2. ported the table to a custome tablespace TX ( no change was made in psrectblspc)
                  3. executed DBTSFIX thru CA

                  The newly generated RELDBTXFIXxx.sql has the create sql with its tablespace as TX ( its a create dummy table, populate data, drop original table and rename table method - i.e alter by table rename). This implies that DBTSFIX is picking up the tablespace name from database metadata and not PT metadata.

                  Now if for some reason the tablespace is different from the actual mapping in the db (as mentioned in the CA documentation), you hav to edit the scripts and reuse the script in all subsequent uprgade passes. i.e skip the step Running DBTSFIX report.

                  RE: So if the REL script adds a new table/index, the delivered tablespace names will be on them where a modification should have the RAC database tablespace name, correct?*
                  Yes, the new tables will be on the delivered PT tablespaces. You'll have to edit the scripts to get them created on your custom tablespaces.

                  RE: I'm also expecting that the projects loaded from file will also ahve the delivered tablespace names on new objects.*

                  The objects (new or existing) will have delivered tablespace names if you have selected Take DDL from source in project copy options. You can either select Keep Target DDL, so that your tablespace mapping for existing tables are preserved or you can fix all the wrong tablespace mappings (for new and existing) by running setspace.sqr once the tables are created in the correct tablespaces (edited RELDBTX script).

                  Its always a good practice to run setspace.sqr after any patching activity

                  Regards
                  Nevin