SBWP transaction - viewing folders/sending documents Long response times

[former_member193294]

Hi all,

I have some complains from some users (about 3-4 out of ~3000 user in my ECC 6.0 system) within my company about their response times on the Business Workplace. In particulat they started complaining about the response time of calling the TCOD SBWP . For 1-2 of them up to 4-5 minutes when myself as well as my other 2 colleagues were getting response of 500ms.

Then they wanted also to view some folders on the Workplace and they had also response times of minutes instead of seconds.

I checked that some of their shared folders as well as the Trash Bin had thousands of PDFs. I told to delete them and they deleted most of them. Stil when they want to open a folder it takes >2 minutes while for me to open the same shared folder takes 1-2 seconds.

I checked in ST03N (user profiles, single records) and 1 of them had long database calls and request time in the Analysis of ABAP/4 database requests (Single Statistical Records).

I am running out of ideas as I cannot explain why only for those 2-3 users happens to have long response times.

Is it related to their folders in the Workplace? Where should I focus my investigation for the SBWP like transactions? Is it the case that some Oracle parameters might need to be checked?

I run the automatic Oracle parameters check (O/S AIX 5.3 , Oracle 10.2 , ECC 6.0) and here are some recommandations:

fixcontrol (5705630) add with value "5705630:ON" use optimal OR concatenation; note 176754 NO 5705630:ON B 1

fixcontrol (5765456) add with value "5765456:3" no further information available NO 5765456:3 B 1

optimpeek_user_binds add with value "FALSE" avoid bind value peaking NO FALSE B 1

optimizerbetter_inlist_costing add with value "OFF" avoid preference of index supporting inlist NO OFF B 1

optimizermjc_enabled add with value "FALSE" avoid cartesean merge joins in general NO FALSE B 1

sortelimination_cost_ratio add with value "10" use non-order-by-sorted indexes (first_rows) NO 10 B 1

event (10027) add with value "10027 trace name context forever, level 1" avoid process state dump at deadlock NO 10027 trace name context forever, level 1 B 1

event (10028) add with value "10028 trace name context forever, level 1" do not wait while writing deadlock trace NO 10028 trace name context forever, level 1 B 1

event (10091) add with value "10091 trace name context forever, level 1" avoid CU Enqueue during parsing NO 10091 trace name context forever, level 1 B 1

event (10142) add with value "10142 trace name context forever, level 1" avoid Btree Bitmap Conversion plans NO 10142 trace name context forever, level 1 B 1

event (10183) add with value "10183 trace name context forever, level 1" avoid rounding during cost calculation NO 10183 trace name context forever, level 1 B 1

event (10191) add with value "10191 trace name context forever, level 1" avoid high CBO memory consumption NO 10191 trace name context forever, level 1 B 1

event (10411) add with value "10411 trace name context forever, level 1" fixes int-does-not-correspond-to-number bug NO 10411 trace name context forever, level 1 B 1

event (10629) add with value "10629 trace name context forever, level 32" influence rebuild online error handling NO 10629 trace name context forever, level 32 B 1

event (10753) add with value "10753 trace name context forever, level 2" avoid wrong values caused by prefetch; note 1351737 NO 10753 trace name context forever, level 2 B 1

event (10891) add with value "10891 trace name context forever, level 1" avoid high parsing times joining many tables NO 10891 trace name context forever, level 1 B 1

event (14532) add with value "14532 trace name context forever, level 1" avoid massive shared pool consumption NO 14532 trace name context forever, level 1 B 1

event (38068) add with value "38068 trace name context forever, level 100" long raw statistic; implement note 948197 NO 38068 trace name context forever, level 100 B 1

event (38085) add with value "38085 trace name context forever, level 1" consider cost adjust for index fast full scan NO 38085 trace name context forever, level 1 B 1

event (38087) add with value "38087 trace name context forever, level 1" avoid ora-600 at star transformation NO 38087 trace name context forever, level 1 B 1

event (44951) add with value "44951 trace name context forever, level 1024" avoid HW enqueues during LOB inserts NO

[michael_mulvey]

Hi Loukas,

Your message is not well formatted so you are making it harder for people to read. However your problem is that you have 3-4 users of SBWP with slow runtimes when accessing folders. Correct ?

You mentioned that there is a large number of documents in the users folders so usually these type of problems are caused by a large number of table joins on the SAPoffice tables specific to your users.

Firstly please refer to SAP Note 988057 Reorganization - Information.

To help with this issue you can use report RSBCS_REORG in SE38 to remove any deleted documents from the SAPoffice folders. This should speed up the access to your users documents in folders as it removes unnecessary documents from the SAPoffice tables.

If your users do not show a significant speed up of access to their SAPoffice folders please refer to SAP Note 904711 - SAPoffice: Where are documents physically stored and verify that your statistics and indexes mentioned in this note are up to date.

If neither of these help with the issue you can trace these users in ST12 and find out which table is cauing the longest runtime and see if there is a solution to either reduce this table or improve the access method on the DB level.

Hope this helps

Michael

[former_member193294]

Hi Michael,

thank you very much for your thorough answer. I will take in account your comments and I will try to carry on my investigations.

I am aware that the format of my question is not the right but I do not know how to correct. Would you have an idea about it?

I do not have the options for formatting plain text.

Best regards,

Loukas

[michael_mulvey]

Hi Loukas,

Hmm. I do not have this problem when I reply to threads. The formatting is always as I type

Maybe you can put your text into Notepad and verify the formatting and see if this helps before you post. But I dont know why the formatting is off

Michael

[Former Member]

Hi,

The formatting is "off" because the original message is longer then 2500 characters.

The SDN forum software was so slow to format correctly long messages that the SDN team decided, as a workaround, to deactivate formatting when the message is longer than 2500 characters.

Nice feature is'nt it ?

Regards,

Olivier