Reorganisation of tables with LONG- RAW fields (TST03)

[Former Member]

Hello Experts,

Looking at the threads raised by my friends, i understand that tables with LONG and LONG-RAW fields can't be reorganised online. So we have to do this offline - using export/import. But this will not be accepted by business every now and then. So please help me in finding a permanent solution.

Our landscape is ECC6 SP17 (non unicode upgraded from R/3 4.6C) and Oracle 10.2.0.4.

1. As per SAP note 835552, 646681, we can convert the tables with LONG, LONG-RAW fields to LOB,CLOB and then do online reorg of these tables.

What are the factors which we need to see whether our system is compatible for this conversion or not.

SAP documents says - performance issues comes after this conversion. Is there any way to find out how much performance degradation would be?

2. We still are using classic tablespace layout - is there any benefit of using new layout.

3. On our demo system, we have done reorganisation of TST03 with export/import method - but still we can see in DB02 - Detailed Analysis - 94% of the space is free. What we need to do to give back the free space to hard disk.

Thanks for your time to read this.

Regards

Davinder

[lbreddemann]

> 1. As per SAP note 835552, 646681, we can convert the tables with LONG, LONG-RAW fields to LOB,CLOB and then do online reorg of these tables.

>

> What are the factors which we need to see whether our system is compatible for this conversion or not.

Well, by reading the notes you already have all the information you need to answer this question.

--> LONG-TO-LOB migration is supported for SAP Kernel 6.40 only if the corrections from Note 988336 was not implemented.

--> The LONG to LOB conversion is not supported for SAP systems with kernels below 6.40.

If you've got a system that has been upgraded to Kernel 7.00 then you can use the LOB-TO-LOB migration.

> SAP documents says - performance issues comes after this conversion. Is there any way to find out how much performance degradation would be?

Sure.

Create a copy of your production system.

Perform the conversion on this copy.

Measure the average times for your most important business transactions on your production system.

Run tests for your most important business transactions that create spool output on the copied system after you migrated the LONG to LOB.

Compare the measurements.

> 2. We still are using classic tablespace layout - is there any benefit of using new layout.

Do you mean you're still using DMTS or are you just referring to the tablespace names?

If you're just talking about the tablespace names and the distribution of segments into them - then the advantages of migrating rather won't add up to the effort for reorganizing everything.

If you're still using DMTS, then you may consider moving to LMTS via reorganization. When you're doing this you can just use the new tablespace layout as well.

> 3. On our demo system, we have done reorganisation of TST03 with export/import method - but still we can see in DB02 - Detailed Analysis - 94% of the space is free. What we need to do to give back the free space to hard disk.

Well, did you drop the datafiles after you exported the TST03? I assume no since there were likely other segments in the tablespace, weren't they?

Basically you've to make sure that there are no extents stored in a datafile anymore before you can get rid of it. To do so, don't just reorganize a single table but the whole tablespace.

That's exactly what's described in note #646681.

regards,

Lars

[thaze_shajith2]

Lars,

Actually the documentation says, LONG to LOB conversion is no longer supported for systems based on the SAP Kernel 6.40 if the corrections from Note 988336 was not implemented.

Your post above says if the note is implemented in Kernel 640, we cannot do the long-lob migration which is incorrect.

Thanks,

Shajith

[lbreddemann]

> Lars,

>

> Actually the documentation says, LONG to LOB conversion is no longer supported for systems based on the SAP Kernel 6.40 if the corrections from Note 988336 was not implemented.

>

> Your post above says if the note is implemented in Kernel 640, we cannot do the long-lob migration which is incorrect.

Yes, right. There is one 'not' too much in my reply:

> > LONG-TO-LOB migration is supported for SAP Kernel 6.40 only if the corrections from Note 988336 was *not--* implemented.

Thanks for pointing out.

regards,

Lars