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.