Heavy DB growth. ECC

[Former Member]

Hi team,

I am going in critical situatiion as my database is growing heavily as my top ten tables occuping nearly 2 GB per day.

SYS_LOB0000106157C00006$$ 491.567

ACCTIT 119.3

FAGLFLEXA 108.9

ARFCSDATA 82.967

MSEG 76.933

BSIS 63.367

ACCTCR~0 61.867

RFBLG 52.8

COEP 42.733

FAGLFLEXA~0 41.9

FAGLFLEXA~3 41.233

TOTAL 1183.567

i AM UNABLE TO TRACE WHY db IS GROWING HEAVY...

I DID REORG ON SOME TABLES..... I AM AFRAID OF THAT LOB ....

IS IT NORMAL GROWTH IN UR PROJECTS???

PLEASE SUGGEST

REGARDS,

sk

[Former Member]

Here is how to get the table name of that lob segment:

SQL> select table_name from dba_lobs where segment_name = 'SYS_LOB0000106157C00006$$';

ARFCSDATA 82.967 -> is this gb? If yes, this is a problem. ARFCSDATA is used for RFC communication, it should not grow that large. Check transactions SM58, SMQ1 and SMQ2 if there is a lot of RFC's stuck, check note [375566 - Large number of entries in tRFC and qRFC tables|https://service.sap.com/sap/support/notes/706478]

Only reorganizing tables will not help unless data was deleted from them. It looks like you have a lot of FI activity on your system, you might need to think about an archiving strategy in the long run.

Cheers Michael

[Former Member]

Dear experts,

LOB SYS_LOB0000106157C00006$$ belongs to Table TST03 and record count is 3,913,757....

RSPO1041 is running successful....

RSBTCDEL job is having log....

****************************************************************************************************

Failed to delete log for job SAP_CCMS_CPH_HRCOLL, count 11181601

Of the 5.543 jobs selected, 2.146 were not deleted

****************************************************************************************************************

we are running more jobs RSBTCDEL2 running max of 5sec....with varient

1000 Job Name S

1000 User Name S

1000 Event S

1000 Event Parameter S

1000 Released P

1000 APREDAYS P 7

1000 BPREDAYS P 7

1000 CPREDAYS P 7

1000 Scheduled P

1000 ASCHDAYS P 7

1000 BSCHDAYS P 7

1000 CSCHDAYS P 7

1000 finished P X

1000 AFINDAYS P 7

1000 BFINDAYS P 7

1000 CFINDAYS P 7

1000 canceled P X

one more RSBDCTL6 is agian running weeekly max 5 sec...

1000 TYP_SES P X

1000 TYP_REC P

1000 SESSION S I C P *

1000 CREATOR P *

1000 DAT_FROM P 00.00.0000

1000 TIM_FROM P 00:00:00

1000 DAT_TO P 00.00.0000

1000 TIM_TO P 00:00:00

1000 PERIOD P 007

1000 STATE__ P

1000 STATE_E P

1000 STATE_F P

1000 STATE_R P

1000 STATE_S P

1000 STATE_C P

1000 STATE_L P

1000 STATE_A P X

RSTS0024 job in 5 sec with varient............

1000 Display Only P

1000 Display and Check P

1000 Delete P X

1000 Maximum Size of the Selection P 20,000

RSBDCTL6 job runs max 2 secs with varient ..................................

1000 TYP_SES P X

1000 TYP_REC P

1000 SESSION S I C P *

1000 CREATOR P *

1000 DAT_FROM P 00.00.0000

1000 TIM_FROM P 00:00:00

1000 DAT_TO P 00.00.0000

1000 TIM_TO P 00:00:00

1000 PERIOD P 007

1000 STATE__ P

1000 STATE_E P

1000 STATE_F P

1000 STATE_R P

1000 STATE_S P

1000 STATE_C P

1000 STATE_L P

1000 STATE_A P X

Please suggest is my varient are Fine to run job successfull ........... any new varient should attach..................

Please suggest any new jobs(currently i am following 16083 note)...

Regards,

Siva

Edited by: skreddy555 on Mar 21, 2011 12:49 PM

Edited by: skreddy555 on Mar 21, 2011 12:53 PM

[Former Member]

Use transaction SP12 -> menu -> Memory allocation to get an overview on where the data is and who owns it. Chances are high, that you are having lots or large spool requests in your system. Check if they are all in the same client, double check the system name and client in the variant of RSPO1041.

There was also a known bug in the kernel lately: [1422843 - Wrong deletion date in spool request|https://service.sap.com/sap/support/notes/1422843]

Cheers Michael

[Former Member]

DEAR CHEEERS,

Thanks alot for ur valuable help.

Memory allocation shows this....

Client TemSe object name Number of Bytes in DB Number of Bytes in File

000 386560 8059200

300 32432413248 319884126

301 0 1301934

Client TemSe object name Number of Bytes in DB Number of Bytes in File

000 JOBLG 0 8059200

000 KONS1 760 0

000 SPOOL 385800 0

300 BDCLG 0 247438072

300 JOBLG 0 72446054

300 KONS1 608 0

300 SPOOL 32432412640 0

301 BDCLG 0 12804

301 JOBLG 0 1289130

Sp01 count is 20.0000 and RSPO1041 varient is

1000 Without Output Request P X

1000 older than ... days P 5

1000 and P

1000 Or P X

1000 Obsolete P X

1000 In Processing P X

1000 older than ... days P 7

1000 and P

1000 Or P X

1000 Obsolete P

1000 Completed P X

1000 older than ... days P 5

1000 and P

1000 Or P X

1000 Obsolete P X

1000 Incorrect P X

1000 older than ... days P 5

1000 and P

1000 Or P X

1000 Obsolete P X

1000 Factory calendar ID P 01

1000 Only include work days P

1000 Include all days P X

1000 System name S I EQ SID

1000 Client S I CP *

1000 Creator S

1000 Title S

1000 Spool request name S

1000 Spool request (suffix 1) S

1000 Spool request (suffix 2) S

1000 Output Device S I EQ XXXXXXXXX

1000 Requests without Output Device P X

1000 Only log without deleting? P

1000 COMMIT all ... Spool requests P 00050

Is anything work around or should i update my kernal....

Kernal version: 700 patch 185

Regards,

Siva

[Former Member]

Well according to your variant, there shouldn't be a spool entry older than 7 days, should it? But that variant looks fine, because if you specifiy 'older than ... days' then the deletion should work properly.

Spool count of 20'000 is ok for larger systems and before updating your kernel you should check if there are spools older 7 days. You should still be able to manually delete the spools or use the method from the sap note.

After deleting more than 50% of the spools you should consider a reorg of the table.

Cheers Michael

[Former Member]

Hi cheer,

RSPO1041 is working fine, and spools are only one week old.

My regrd is can i do any thing to regularize/decrease my DB growth, especially TST03 and RFC table.

Is there any activity to resize or delete(other than reorg) unwanted data from my tables....

Regards,

Siva

[Former Member]

Can you confirm:

TST03 (lob segment) is 491gb on your system (491mb would be ok, 10-20gb would be ok too, but 491gb isn't)

ARFCSDATA is 82gb on your system (a size of 1-5gb or smaller would be ok)

How large is the database in total?

The SP12 check shows that "only" 32.432.412.640 bytes (~30gb) are occupied in the database. So something is wrong. It is possible that the data is already deleted so you would get ~450gb space back with a reorg.

For the RFC tables you need to do the checks i told you earlier.

Is there any activity to resize or delete(other than reorg) unwanted data from my tables....

Theoretically if you have an ASSM tablespace then a segment shrink would be possible too, but you would need to research the howto yourself. I recommend to use the official SAP supported reorg method with brtools.

Cheers Michael

[Former Member]

hi M,

TST03 is nearly ~50 GB, i specified is dialy change ~500MB.

ARFCSDATA is also ~50 GB daily growth is ~90MB

wat about my ACCTIT ACCTRC* tables is ~50 GB, can i handle by shrink method??

My DB size 1100 GB, my proj is 3 yr old.

please suggest me a super solution....

Regards,

Siva

Edited by: skreddy555 on Mar 21, 2011 5:14 PM

Edited by: skreddy555 on Mar 21, 2011 5:18 PM

[Former Member]

Well regarding TST03 i would try to reduce the spool size. Use transactions SP12 and SP01 to find who produces the most spool and ask him about that. Often lots of spool is generated by accident and never printed or reviewed.

ARFCSDATA should not grow, data should just pass through this table, something is most probably wrong there.

The other tables are real application tables they contain FI/MM data. The problem with FI data is that it often needs to be kept for years for legal or tax regulations. As i said earlier you will need to establish an archiving concept, all these tables have archive objects in transaction SARA. This will need a good amount of work and you have to involve application people and FI / MM consultants to figure out a concept.

Cheers Michael

[markus_doehr2]

BTW: writing in CAPITALS only means SHOUTING at people.

> i AM UNABLE TO TRACE WHY db IS GROWING HEAVY...

Is there any project started? Any batch inputs on the system running? Big user activity? 2 GB/day doesn't sound that much to me.

Markus