Software Update Manager: Clean up tasks, Shadow Instance & Temp. Tablespace X

[Akshay_G]

Hi Experts,

I wanted to know that after an upgrade activity using SUM (Software Update Manager) how should I proceed with the cleanup tasks.

As SUM uses a shadow instance for the upgrade and for which a temporary table space is required, we can release some space once the upgrade has completed, right?

In my case (SPS08 upgrade in Solution Manager 7.1), a temporary tablespace PSAPSR3702X of 32GB was required before execution.

So I created that in order to upgrade my system.

My upgrade went successful, and now I would like to cleanup the space that was occupied during the upgrade.

I believe that scope here for cleanup is:

1) The temporary SAP Tablespace PSAPSR3720X (32 GB), data file is under /oracle/<SID>/sapdata4

2) SUM Directory (Upgrade directory /usr/sap/<SID>/SUM, which is 21G and contains the logs,files, shadow instance)

What should be the approach to process the clean-up post upgrade?

A) Is this approach feasible?

1. Stop SAP & DB
2. Drop SAP Temporary Tablespace
3. Drop SUM Directory
4. Start SAP & DB and validate

I also looked up SAP note 1732061, which is central note for SUM, it talks about, Do not select "Cleanup and start afresh" before finalization.

So in the postprocessing phase after the upgrade completes and just before Finalization phase, I have selected "Continue" as per the above mentioned note during the upgrade.

B) Or is it that, if I start SUM again and I get an option in the beginning "Cleanup & Start Afresh" which shall do the necessary cleanup, though I am not really sure, if this the possible feature of SUM!

Which is the correct approach? Could you please suggest, as I have worked with SUM for the first time.

Regards,

Akshay.

[Reagan · Accepted solution]

Hello

During the upgrade SUM tool asked you to create a tablespace called PSAPSR3702X for the upgrade activity.

The shadow system was created with this tablespace.

The table space is NOT a temporary tablespace, instead this is the tablespace where the upgraded components reside.

The reason why SUM tool suggested to create tablespace with the name PSAPSR3702X is because there is already a tablespace with the name PSAPSR3702.

If you check the system the tablespace PSAPSR3702 will be empty now. This is normal after an upgrade activity using the SUM tool.

There are two options for you:

1 - Drop the tablespace PSAPSR3702 as this not used anymore.

2 - Do a reorganisation to the tablespace PSAPSR3702X to PSAPSR3702 and then drop PSAPSR3702X.

Important :

Before you drop either of the tablespaces (The empty one) you need to first make sure that there are NO objects in either of the tablespaces (PSAPSR3702X PSAPSR3702).

You need to use BRTools for this activity.

There is no need to run the cleanup tasks for this and I doubt whether that will get the desired output.

Regards

RB

[Akshay_G · Accepted solution]

Hi Reagan,

Thanks for such an insightful clarification.

Yes, indeed I see that PSAPSR3702 is absolutely free now.

All data has been moved to PSAPSR3702X along with the upgraded SAP System.

I should opt for dropping PSAPSR3702 as it is 18GB.

If I re-organize from PSAPSR3702X to PSAPSR3702, I will have to extend it first up to the required size.

But to avoid any confusions, rather I should be doing re-organizing from PSAPSR3702X back to PSAPSR3702 and then drop PSAPSR3702X.

What do you think, should be a stickler approach? I don't have any limitations/constraints on this!

I would prefer the latter approach, I guess.

Two more curious queries:

1) If I intend to keep PSAPSR3702X and drop PSAPSR3702 and do a second upgrade via SUM, it will required another tablespace? Or is it possible that if I extend my tablespace big enough, to upgrade the system it will work? What is the reality check here? How does this work? i.e. To have  a new tablespace and upgrade the system in there and then switch over?

2) What do you think of the SUM directory, its around 20GB and contains the DVEBMGS02 (Shadow Instance) mainly. Complete SUM directory can be dropped, without any consideration, if the upgrade has happened successfully?

Let me know, what you think?

Best regards,

Akshay

[Reagan · Accepted solution]

Good Day Akshay

What do you think, should be a stickler approach? I don't have any limitations/constraints on this!

For sure you can reorganize the PSAPSR3702X to PSAPSR3702 and drop PSAPSR3702 if you know how to proceed with that.

Two more curious queries:
1) If I intend to keep PSAPSR3702X and drop PSAPSR3702 and do a second upgrade via SUM, it will required another tablespace? Or is it possible that if I extend my tablespace big enough, to upgrade the system it will work? What is the reality check here? How does this work? i.e. To have  a new tablespace and upgrade the system in there and then switch over?

If you do an upgrade to the SAP components within the same release/EHP the tablespace will have the same name but with a different extension, maybe somthing like PSAPSR3702X1.

Check this link for SAP tablespace naming conventions:

http://help.sap.com/saphelp_nw70/helpdata/en/9f/4a56b2185851468b39b719daa2d3aa/content.htm

2) What do you think of the SUM directory, its around 20GB and contains the DVEBMGS02 (Shadow Instance) mainly. Complete SUM directory can be dropped, without any consideration, if the upgrade has happened successfully?

The shadow instance has no relevance once the downtime has been completed.

During the downtime phase the system does a switch of the shadow instance to the main instance with the new kernel and that is the reason why the SUM tool prompts you to back up the database, the upgrade directory and the old kernel before you proceed with the downtime phase.

If the upgrade has been completed the you may finalize the steps in the SUM tool and then complete all the post upgrade activities and remove the upgrade activity.

Regards

RB

[Akshay_G · Accepted solution]

Hello Reagan,

First of all apologies, for such a long delay in response. I kept it open deliberately, because I wanted to check this out before closing on.

However, few other deliverable's came up and I could not check this out.

I will be closing the thread for now and will implement it later and will get back to you on how it went, which I think will be a total closure.

Many thanks for the clarification!

Best Regards,

Akshay.

[do_thikimdung]

hi Akshay Gupta

when I upgrade SAP solution manager 7.1 from sp04 to SP12, this message appeared:

"Insufficient free space in the database as follows. Please refer to file E:\upgrade\SUM\abap\log\DBFPLUSD.RES for more details and additional information about the results of the free space check.

Create TABLESPACE PSAPSR3702X with 25041 MB

INFO: To adjust the size of your tablespaces, you may use the commands

in file 'E:\upgrade\SUM\abap\log\ORATBSXT.LST' using the 'brspace' utility.

Please copy the file before making changes, as it may be

overwritten in subsequent upgrade phases.

You must fulfill these requirements first before you continue with the procedure!

Free space recommendation

In some scenarios there might be more space required, which was not part of the calculation. Therefore we recommend to have up to 20% more free space than overall required:

Additional 5008 MB to TABLESPACE PSAPSR3702X"

I open file ORATBSXT.LST then i copy a command : "brspace -function tscreate -tablespace PSAPSR3702X -class none -data both -size 200 -incrsize 200 -maxsize 25041 -autoextend yes"

Then I run this command but above message still appears

How can fix this error ?

please, can you help me?

thank you

[former_member25156]

Hi -

We have an SUM related question. We are upgrading an ECC System, and something happened with the upgrade where, in the SUM directory, the following folders were deleted in /usr/sap/put/SUM:

bin

bin_nuc

buffer

cofiles

control

data

exe

htdoc

There were no processes running at the time, and it was at the prompt to start downtime, phase : DOWNCONF_DTTRANS

After looking into the (already upgraded) QA SUM directory, I could do a compare, and saw that we can potentially use the folders from QA and copy them over and restart the SUM tool. Is this something to consider? Or do we restart the whole process?

Thank you!

[rajarshic]

Hi Ronald,

If you are using the same version of SUM and target software components both for QA and the present environment, it should not be much issue except the fact that the directory HTDOCS contain information in the form of log files about how the entire process was executed till your downtime phase (like software components selected and execution time for each phase) for your DEV environement which you can't replace with the QA one. I'd suggest to reset the upgrade process after restoring the QA directories and see how it progresses.

Thanks

[Former Member]

Hi Ronald,

from my point of view also, a restart of the upgrade is essential. The data and cofiles under SUM directory directories include upgrade-specific transport files.

Regards.

Serhat

[Former Member]

Hi Experts,

I hope i am not much late in this topic i facing similar problem after i upgrade my ECC6.0 system to ECC6.0 EHP6.I need all of your suggestion on this.I a Newbie in Upgrades and organizing table spaces you help will be appreciated. 

What are the steps i should perform as you can see OLD Tablespace PSAPPRD700 not free.

Regards.

Gohar Mustafa

[Reagan]

926 Segments in the PSAPPRD700 tablespace compared to 891 segments in the PSAPPRD731 tablespace.

Did you really perform the EHP upgrade as advised ?

First make sure that everything is OK with the upgraded system.

Use BRTools tbreorg function to move the contents of the PSAPPRD700 tablespace to PSAPPRD731 tablespace.

Regards

RB

[Former Member]

Hi RB,

Thank for you valuable comment.

926 Segments what does it means it should be equal while comparing both releases tablespaces?

Yes,I have perform EHP6 upgrade and have full summary report with status components EHP6.

i have received few errors in ST22 for PXA NO FREE SPACE.

What are those other steps to see upgrade system is OK?

Ok BRtools i will use to move the contents i guess from space management option.

Thanks and regards,

Gohar Mustafa

[Reagan]

su - orasid

brspace -c force -o process,time -u / -f tbreorg -a reorg -tablespace PSAPPRD700 -t "*" -parallel 3 -degree 3 -newts PSAPSR3731

Good Luck

RB

[maruthiprasad_nissankarar]

Hello Akshay,

In shadow Instance (usr/sap/sid/sum/abap/<sid>) which data exactly is cloned from the original system into the shadow instance. Suppose to say that my total data base size is 300gb.

Thanks,

Maruthi.

[Akshay_G]

Hello Maruthi,

Have you read this post completely with all the comments?

To answer with your query:

Reagan Benjamin wrote:
During the upgrade SUM tool asked you to create a tablespace called PSAPSR3702X for the upgrade activity.
The shadow system was created with this tablespace.
The table space is NOT a temporary tablespace, instead this is the tablespace where the upgraded components reside.
The shadow instance has no relevance once the downtime has been completed.
During the downtime phase the system does a switch of the shadow instance to the main instance with the new kernel and that is the reason why the SUM tool prompts you to back up the database, the upgrade directory and the old kernel before you proceed with the downtime phase.

I believe your are trying to get an estimate on required free space for performing upgrade using SUM.

Based on your tablespace PSAPSR3702 or similar you shall be prompted to create additional tablespace PSAPSR3702X of specific size. The size of the shadow instance directory depends on this size.

For your ref:

1) Size of PSAPSR3702 before upgrading with SUM=> 18.5 Gigs

2) Size of new Tablespace PSAPSR3702X => 32 Gigs 75% Consumed

3) Size of PSAPSR3702 after upgrade => 18.5 Gigs 100% Free

4) Shadow Instance Directory Size => Approx. 21 Gigs.

-Akshay

[maruthiprasad_nissankarar]

To be Honest no.

But,

I greatly admire the way of your response...

Thank you so much Akshay.

[Reagan]

Hello

The database content is not copied to /usr/sap/sid/sum/abap/<sid>

The upgrade activity only works with the repository data.

There will be only one database for the main system and the shadow system.

The file system /usr/sap/sid/sum/abap/<sid> is used for the upgrade activity where the shadow instance is created along with the upgrade activity logs, etc.

Read these discussions:

http://scn.sap.com/thread/3414014

http://scn.sap.com/thread/3410181

Regards

RB

[maruthiprasad_nissankarar]

Hello Reagan,

The discussions really helped me a lot....

Thank you Reagan.

[Nibu]

Hi Akshay,

Do not select the cleanup option now, you are supposed to finish the process.

Once finished , you can go ahead cleaning up the SUM directory and dropping of unused tablespace . I reccomed you do this dropping first at your staging server before proceeding the dev/qa/prd .

[Akshay_G]

Thanks Nibu, for the feedback.

As we don't have a central SUM staging area, we will clean up the local SUM with shadow instance and drop the tablespace which got freed during update.

Thanks,

Akshay.