Our Company currently undergoes a data archiving project. We plan to perform a database reorganization as a follow-up step when everything is done.
OS: AIX 5.1
Database: Oracle 188.8.131.52 with current DB Size 800GB
SAP ECC 5.0
I would like to ask if we can use R3load to rebuild the system instead of using the ways specified in Note 646681? (As I can see, the best way to get it done is to do offline reorganization, which take quite amount of time and disk space of course)
What would be the difference between R3load and database reorganization in Note 646681 in this case?
Since you have perform database archiving you may have the list of archiving objects using which data has been archived.
Using the archiving objects you may find the linked tables in Tcode SARA.
Based on your scenario I would suggest you to perform table reorganization based on SAP note 646681. You may perform selective reorg and schedule it as per convenience. You may use brtools to perform the require activity.
Additionally See Note 806554, which describes the options available for optimizing the reorganization performance (for example, parameter setting, parallel processing).
R3load method is useful in case you need to perform system copy or unicode conversion or when the database size is in Tera bytes and reorganization take huge time. You may run several R3load processess based on CPU and RAM on the server to export your database and then re-build the system using the export dump.
Since your database size is not that high ( 800 GB), my recommendation would be to perform table reorganization.
Thank you very much for the response.
Actually, our company is lacking storage. In this case, if R3load can achieve the purpose of a database reorganization, I will go for R3load since it needs less storage and most importantly downtime.
What's the technical difference between R3load and the one specified in Note 646681 ?
If R3load is technically equivalent to database reorganization, it somehow makes no sense to perform database reorganization because the downtime is high and it consumes lots of disk space.
Technically R3load and database reorg using brtools is different. Internal operations are different both the tools.
R3load makes use of .STR, .TSK files to perform export/import.
For space issue resolution, you may go with R3load option as it will be faster then database reorg using brtools.
Ensure that you get enough downtime for the same.
R3load since it needs less storage and most importantly downtime.
The thing is with R3load you do an export/import of tables (always offline), with brspace you are able to do online reorg.
R3load is mainly used to do system copies, migrations and full database exports, while brspace is used to reorg single tables and tablespaces.
brspace reorgs are easy, R3load is more sophisticated. I too would suggest you start with online reorganizing the big tables where you deleted data with brspace. The space will be freed within the corresponding tablespace and can be reused by other tables there.
Reorganization via R3Load happens naturally since you're doing the Export/Import of Database. It's a part of overall movement of DB which I personally do not think is a good idea when you're looking for reorganization alone.
Since it is 800 GB I would suggest you do online reorganization of tables with BRSPACE.