How to remove newly applied support pack.

[Former Member]

Hi all,

i applied support pack in my R/3 4.7 server.

if any procedure for remove already applied support pack.

Regards.

Satish

[former_member204746 · Accepted solution]

only way to "uninstall" a support pack is to restore the backup you took before applying the support pack. every change made after the support pack will be lost.

sorry, but this is the way this works.

[Former Member]

Hi satish,

If you want to delete the queue you have delete the entries from table PAT01 & PAT 03.

Connect to oracle as sysdba in NT/oraSID in UNIX use command

delete from sap<sid>.pat01 where PATCH='<sapkhxxx>';

commit;

delete from sap<sid>.pat03 where PATCH='<sapkhxxx>';

NOTE:Please be cautious before mentioning the patch, it is advised to take the back up of pat01&03

commit;

regards,

kanthi

[markus_doehr2]

No - this is wrong.

This will just revert the status you see in SPAM but it will NOT take back the changes already made to the system. If you're stuck in a specific phase and SPAM doesn't let you revert, then it's too late already.

In my last 13 years I never needed to set back the queue by manually fiddling with the PAT* tables, it's advised to find the root cause for a failing import, not trying to "trick" the system back to an older state.

--

Markus

[lbreddemann]

Hi all,

please be aware that manipulating the contents or the structure of the database tables directly via tools like sqlplus will end your sap support for this system.

The only exception to this rule is if your asked and instructed by the SAP support or by a recommended note to do so.

In all other cases you can do massive harm to your system and often cause problems that cannot be fixed anymore. In these cases the restore of a backup would be the only "solution" then.

Therefore: better keep away from sqlplus to access/change data in your database!

KR Lars

[Former Member]

Lars,

That's a very interesting statement...

Do you know of any OSS note or support contract that puts that in writing?

That seems kind of harsh...

For example, when many folks perform database copies users are recreated at the sqlplus level.

Many table entries are changed via sqlplus (to speed the post tasks along)...etc...

I'm not trying to argue just trying to see if you have some documentation to that effect...

[lbreddemann]

Hi Somckit,

sorry if it sounded too harsh - usually the SAP support helps as much as possible in any cases even if the problem was caused by wrong handling.

Nevertheless changing data via sqlplus is a modification to the system.

And as of note <a href="http://service.sap.com/sap/support/notes/83020">#83020 - What is consulting - What is support?</a> modifications are not eligible to be supported and it may require consulting to fix problems that result from such modifications.

Of course - it's always customers system and they can do with it, whatever they like to, but not anything will be supported.

Technically there are for sure many options to "tweak" the system and go around some issues - but as many things look easy and obvious in the first place there are often "strings attached" that introduce dependencies that are only known to the developer. Besides the legal-kind statement from the note, this is the bigger danger I see.

You change something where you think you know what happens and then something else does not work anymore or changes its behaviour. It's just then when your upgrade schedule goes down the toilet...

Concerning the statement about database copies and users - what users do you mean here? OPS$-users? For that there are specific notes that explain what and how to do.

What table entries are you talking about to "speed the post tasks along"?

KR Lars

[Former Member]

Yes, you're correct about re-creating users...

Regarding the tables changes for post tasks...

Some may choose to:

1) truncate tables (i.e. moni, tbtco and various other logging tables)

2) import saved RFC destinations via exp/imp (i.e. RFCDES tables)

3) update certain tables to reflect the env (tsp* tables for new print server)

and so on...

You can certainly do all these activities from SAP but is not quite as fast and efficient...

[lbreddemann]

Hi Somckit,

well, let's see:

1.) Truncate some tables... yes, that supported by specific notes

2.) Using Exp/Imp ... I didn't find any note for that. Since in general the usage of exp/imp is not supported in SAP systems (except when used with brtools), I would consider this unsupported as well.

3.) Didn't find any not for that either.

As I wrote earlier - these changes may work.

But in case of problems these kind of "bypassing"-activities may be the reason for a restore.

The problem is: sqlplus (or other db-tools) don't protect you from damaging the database. It just does what you ask for and never asks back.

It quite happens that customers, especially those who are really experienced and get used to "do things their way", just enter a command with a typo in the tablename and that's it.

E.g. truncating the wrong table - no rollback possible, database needs to be restored/recovered.

What I'm saying is: before trying such things on your own, make use of your maintenance fee and open a support message. Ask if the actions you plan to do are OK and/or look for notes that explain the exact procedure.

KR Lars

[markus_doehr2]

1) truncate tables (i.e. moni, tbtco and various

other logging tables)

You can use SE14 - "Activate and adjust table - delelete data" (which will drop the table an create it again)

2) import saved RFC destinations via exp/imp (i.e.

RFCDES tables)

We use R3trans for this purpose (see the method of note 130906)

3) update certain tables to reflect the env (tsp*

tables for new print server)

same as above

@Lars: to your last comment: It´s right, one can always create OSS calls but: Not all components react as fast as those you are working in, sometimes you create test-/sandbox systems, that need to be set up right

now

and not somewhen in the week. The basis people in the support are VERY different here, than those from the application, I could tell you stories...

Additionally there comes another aspect to those OSS calls: If you work in a certified competence center, you

must not

create more than a specific amount of calls each year which are classified by the support people as "not fullfilled", otherwise you will pay additional maintenance fees and probably loose your certification. A certified CC is advised (by contract) to "help itself" before creating calls - and this is what people do when they are "sqlplus´ing" before taking the risk, to get a note attached with "individual solution" and a minus point on their side.

SAP internally those problems never arise and many people I talk with, aren´t even aware of those restrictions concerning a competence center and argue to "create one call for each problems". Unfortunately there´s nowhere a comprehensive documentation available, how to do those post-copy works (and others) in an efficient way. Landscapes are huge today and it would take customers days and days e. g. creating/changing RFC destinations by SM59. The size of those landscapes is in most cases not defined by the customer but by SAP creating new/additional products - so an house made problem leaving the customers alone how to deal with after a system copy because internally those problems never arise.

Just my EUR 0.02

--

Markus

[lbreddemann]

Hi Mr. Döhr,

thanks for the accolade

As usual, the individual people that do service are the linchpin of it.

There's not too much more to say about this...

Of course I'm not that far from reality that I don't see the need of efficient landscape handling techniques.

As you surely know, this IS a topic for SAP now for a long time. Our hosting services face very similar problems than customer landscapes.

This "landscape management" was - afaik - at least one of the good intentions behind new products like solution manager.

Anyhow - and this is my very personal view only and of course in no way the view of SAP - these solutions seem sometimes like "breaking a butterfly on a wheel"...

The CCC-situation is also something I'm aware of. Saving maintenance fee on this way does come with a different kind of costs, that's for sure.

I also agree that for the overall solution at a customers site it's not easy to get hold of a comprehensive, current and well accessible documentation. All I can say about that is, that people working on this topic to make the documentation more available to everybody. A big obstacle with that is surely that customer landscapes differ widely and nearly all aspects.

I'm used to think of SAP solutions as a kind of factories. Although you can actually buy factories today for many standard production processes it's likely that the one you get will differ from every other factory. Documenting such a factory will always require individual changes.

In a way this is 'the curse' of highly customizable products.

best regards,

Lars

[markus_doehr2]

thanks for the accolade

well... it´s true - and I highly appreciate it.

As you surely know, this IS a topic for SAP now for a

long time. Our hosting services face very similar

problems than customer landscapes.

This "landscape management" was - afaik - at least

one of the good intentions behind new products like

solution manager.

Anyhow - and this is my very personal view only and

of course in no way the view of SAP - these solutions

seem sometimes like "breaking a butterfly on a

wheel"...

Not only that, it doesn´t help in those 1000 basic tasks like those mentioned, it even makes it worse, much worser, than any sqlplus statement can do harm to your system. Without wanting to step on someones toes and with all appropriate respect: It´s a typical prove for an example of highly educated academical but theoretical people trying to solve practical problems - It´s getting better, no doubt, but there´s still a pretty long way to go before it will really help.

I´m of the opinion: If SAP has the strategy "everything is in the database", then please give us tools to maintain that data, if you don´t want people to do that manually using database tools. A "maintenance optimizer" guided procedure is certainly nothing, that really helps

The CCC-situation is also something I'm aware of.

Saving maintenance fee on this way does come with a

different kind of costs, that's for sure.

Full ack.

I also agree that for the overall solution at a

customers site it's not easy to get hold of a

comprehensive, current and well accessible

documentation. All I can say about that is, that

people working on this topic to make the

documentation more available to everybody.

The documentation is there, it´s just the vast amount of it killing brains.

If I as administrator need to keep all those things together, like dependencies between SPs, connections to other systems, codepage issues, printers and all that stuff you deal with every day, why can´t someone from SAP do the same? I mean, SAP expects administrators to do that, why don´t they do it on their own? There are of course tools to assist (System Landscape Manager, Self Diagnose etc.) - but they are all different, all have their own glitches and additional notes, patches etc. you have to deal with ON TOP of all to make them usable for you and they all have a pretty isolated view on an isolated problem.

As said before, all data is in the database, so use it

A big

obstacle with that is surely that customer landscapes

differ widely and nearly all aspects.

...driven by customers? certainly not. You as SAP say "We don´t extend SD functionality any more, use CRM" and "we don´t extend purchase in ERP any more, use SRM" - but they totally forget to keep the customers able to manage those systems, interdependencies, spoken plain technically without even digging into the applications themselves. Example:

- SRM needs a new SP

--> dependency to a specific the PI_BASIS in R/3

--> upgrading PI_BASIS needs a SPAM update

--> SPAM update needs a new tp/R3trans

--> tp/R3trans needs a new SQLDBC/Oracle/DB2/libdb 1,000,000 notes - and finding them is impossible, you will probably do the "try-and-error" approach here because there´s simply no chance to get that information at once - because of "isolated problems", isolated groups and abstraction over abstraction.

I'm used to think of SAP solutions as a kind of

factories. Although you can actually buy factories

today for many standard production processes it's

likely that the one you get will differ from every

other factory. Documenting such a factory will always

require individual changes.

I don´t think so.

If you have an ERP, CRM and SRM system, they have some sort of connections between them, this is common on all scenarios and is nothing, that is customer specific. On one side you "force" customers to use new products, on the other side you have no tools on side to REALLY´maintain those systems in a landscape aside from a Solution Manager software, that itself needs more maintenance, more mandays of configuration and more nerves to configure than all our systems together when done manually.

And there´s stil no "support package rollback" function

--

Markus

[lbreddemann]

Hi again,

it took me a while to think carefully about a reply to your previous post.

First of all I'd like to assure that I get your point and can follow it - although not completely agree.

Having seen some other companies before entering SAP I recognize a recurrrent development when producing customizable products.

The more flexible and adaptable and put-in-any-favorite-buzzword-that-says-'this-solution-is-for-you'-here a product becomes the further moves the product development away from individual customers.

"The market" becomes, at least partly, the target group for the product development.

In that there lies a big danger to loose customer confidence and connection as well as the chance to push development further than what is possible beeing driven by customer requests.

Basically the question is in my eyes: who's leading the development? Is it the customer with its requirements or is it the producing company with its development divisions?

Looking back I find that the products and solutions SAP has to offer are the result of a mixed strategy. There are many parts where SAP has learned from its customers what is needed and how its needed. There are many parts as well where SAP came up with innovative or at least clever solutions to problems that remained unsolved for long.

To me this mixed approach would also be the right choice for the future - anyhow, I'm not involved in any strategic decisions.

It's not like - sure not - that I don't see many insuffiencies and things where I think that should be improved. But looking down the hill we're standing on I've to say: wow, it's already gone that far.

There are many things that had been done right where others are still failing to catch the point.

Beeing inside SAP my effort goes into improving what we have and helping customers to get the most of what they bought.

As a customer ... I assume everybody knows how to interact efficiently with suppliers

Best regards,

Lars

p.s.

sorry if this discussion went off-topic.

Next time I'll move to another forum, promised!

[markus_doehr2]

In that there lies a big danger to loose customer

confidence and connection as well as the chance to

push development further than what is possible beeing

driven by customer requests.

Yes - you´re right - customer feedback is not ignored, that´s true but:

In "earlier days" there was a program named "FCS - First Customer Shipment" - where customers could get alpha/beta software, implement and test it and give feedback. Nowadays, that is called RampUp and need to be payed by the customers. In fact this means: If you have the $$$ (€€€) and want to have a small influence then you can do it, if not then, well, you´re lost at that point.

It's not like - sure not - that I don't see many

insuffiencies and things where I think that should be

improved. But looking down the hill we're standing on

I've to say: wow, it's already gone that far.

There are many things that had been done right where

others are still failing to catch the point.

Absolutely.

If I personally wouldn´t enjoy (to some extend) to work with SAP, with the support and with people in the backoffice, I wouldn´t do the job. Thanx God, there are people in the support who really care and who are seing customer problems as a challenge and not as a problem.

My main concern is: Is it managable? I´m working in a medium size company with SAP products for about 13 years and I´ve had all kinds of ups and downs with various versions of the classical R/3. We had three or four systems, that we were able to manage nicely. Now we have > 70 instances of various products because of SAPs strategy (not because of our choices) and basically, we´re doing not really much more than some years ago; (we still use VA01 and MIGO) - the processes became different, it´s the tools we use, that are different. Managing such an environment with the same manpower as we had at the "times of 3 to 4 servers" with tools, that are in my opinion not yet ready for prime time, is a challenge, no doubt, but it shouldn´t end it "managing the managability".

As a customer ... I assume everybody knows how to

interact efficiently with suppliers

&#1613;Speaking of ICH/SUS/SRM, yes, the products may be nice and nifty, and most probably they will do as told on the high-gloss powerpoints but: If I need at least 6 systems (SRM, XI/PI + SRM-CAT, for test and production) then, well, you must allow the question of reasonability from a technical point of view.The invest you will need (not speaking only of hardware) and the amount of time to manage such an environment will eat up almost all benefits you get (I just did that calculation some weeks ago).

Just think about what it will mean to make a system copy from your production ERP to your test/QA one, if you have all those products (SRM, ICH/SCM, PI. Portal...) working and running. It´s a nightmare, more than that, worst scenario ever because it will take you WEEKS to get everything fit together again because there´s no tool available to assist you.That´s my personal big criticism and that´s why I most often argue internally against yet-another-system and yet-another-engine.

This may be because of your rather not-so-big company size, other companies may see this differently but we only have 2,5 persons to install/upgrade/manage/backup/restorepatch/tune all those things. It would often be MUCH easier to add a new functionality into the ERP without all the additional things on top.

I´m a techie and I like challenges but exaggeration is never a good thing

--

Markus