Reorg tables in 8.1.7

I'm planning to reorg 500+ tables in 5-6 schemas from prod. instance to new one. DB is 8.1.7.4
I'm thinking on using 2 approaches:
1) using db cloning from current prod. to new then re-org selected tables to different tablespaces, or
2) export tables using table mode than import to new prod. by chaning default_tablespace for target user.
Which is better option if objective is to re-org tables to different tablespaces within schemas. Also want to use new lay-out mgmt, i.e. change dictionary to locally managed, tune the new instance, etc.
Thanks in advance.
BAM

Or just create a database link from your new box to the production box. You can then run CREATE TABLE new_name AS SELECT * FROM old_name@the_db_link; Though INDEXES will not be created...

Similar Messages

How to find out the failed reorg tables during reorgnization phase

Dear All,
I am doing the archiving project.
I have finished the Write phase and Delete Phase.
Now I am doing the tablespace(PSAPSR3) reorganization in QAS(Offline).
Due to the redo log space was full during the reorgnization phase.
Some tables' reorgnization progress were failed.
Hope you could tell me how to find out the tables which reorgnization were failed.
(DB level? OS level? SAP Level?)
Thank you in advance!
Jason

/oracle/QAS/sapreorg

Table Reorg in R/3 System - eligibility of the table for reorg

Hi Experts,
We want to perform Table reorg in our R/3 system 4.7 EXT2. We have taken out top 10 tables which are candidates for table reorg based on Size, could you please let me know the below :
How i can check that each table is eligible for table reorg or not?
Which are the tables that can be excluded from table reorg ?.
Please let me know is therte any procedure for the same.

Hi Bablu,
Refer to the link below
http://janpreetdba.blogspot.in/2013/08/reorg-table-and-index-storage-quality.html
This will help you filter our tables and indexs having poor storage quality and can be a candidate for reorg.
Hope this helps.
Regards,
Deepak Kori

Unable to include VARI table in "Tables Excluded from REORG" No Edit options

I am trying to remove the table VARI from the automatic reorg in the dbacockpit.
Steps followed :
-> Configuration
-> Automatic Maintenance
-> Automatic REORG
-> Tables Excluded from REORG
Issue : Unable to include VARI table in "Tables Excluded from REORG" No Edit options .

Hello Arun,
Automatic reorg of the tables/indexes is done on the basis of result provided by script REORGCHK which runs on regular basis to analyse the table with huge growth and more fragmented blocks.
Since the default filter for reorg is set to size' 1,000,000 KB', table which has bigger size than the default value, needs to be reorganized as per the standard configuration.
To exclude table VARI, modify the filter clause, and update the policy using procedure Automaint_set_policyfile(). You then can verify again using automaint_get_policyfile(). The procedures are documented in the IBM DB2 InfoCentre. If you need assistance, please let me know.
I suggest to take the exported policy, and just add table VARI in the filter clause. The section could read as follows.
========================================================================
<FilterClause>TABSCHEMA NOT LIKE 'SYS%' AND (TABSCHEMA, TABNAME) NOT IN
(SELECT TABSCHEMA, TABNAME FROM SYSCAT.EVENTTABLES) AND (TABNAME <>
'VARI')</FilterClause>
========================================================================
Then apply this policy, and check results.
Please provide feedback.
Best Regards,
Gunjan

Will reorg of tables and reindex of indexes help ? And How?

Suddenly users told that one of their applications has become very slow. They identified millions of history data also, which they deleted . But still it did not help. Should we go for reorg of tables and reindex of indexes? Will this at all help ? Will this help to gain space ? or It will help in speed ? How should I do it ?
Reorg tables
1. First take export dmp of all the tables of that particular schema.
2. Then truncate the tables.
3. Then import that export backup.
reindex indexes
1. Find out how much space is used by the indexes.
2. Add that much of space in a different tablespace
3. then move the indexes there.
I am not sure about the steps which I missed. I need some advice from you.
And how can I gain the space in the Unix server after this delete operation?

With problems like this, I think that the first response should not be that we need to reorg tables/indexes. Steps are as follows.
1)Ask users what portion of app is running slow? and how much slow.
2)Also as others have suggested generate awr report or statspack or estat/bstat and see where time is being spent?
3)Problem could be that execution plan of some sqls may have changed and they may be performing badly. This is the most likely reason. Other problem could be that there is some other contention in database or there is an I/O problem. All these you can find from these reports.

CI_ANLU structure in the table ANLU(R/3 System)

Hi,
Cud u pls tell me what is the CI_ANLU include structure(which is not defined) in the table ANLU. Due to CI_ANLU structure, I am gettig following error:
TRANSF_1_1_1> [ZBAPI_FIXEDASSET_GETLIST_RFCSSCallFunction_17408] [ERROR] [SAP STATUS: E] [SAP MESSAGE NUMBER: 016] RFC function call with IntegrationID [3.000000000000000] reported ERROR status in [RETURN] RETURN structure.
[SAP MESSAGE: Customer enhancement not active or structure CI_ANLU not defined].
Plese let me know about this error urgently.

Hi Bablu,
Refer to the link below
http://janpreetdba.blogspot.in/2013/08/reorg-table-and-index-storage-quality.html
This will help you filter our tables and indexs having poor storage quality and can be a candidate for reorg.
Hope this helps.
Regards,
Deepak Kori

Index size greated then Table Size

Hi all,
We are running BI7.0 in our environment.
One of the tables' index size is much greated than the table itself. The Details are listed below:
Table Name: RSBERRORLOG
Total Table Size: 141,795,392 KB
Total Index Size: 299,300,576 KB
Index:
F5: Index Size / Allocated Size: 50%
Is there any reason that the index should grow more than Table? If so, would Reorganizing index help and if this can be controlled?
Please letme know on this as I am not very clear on DB much.
Thanks and Regards,
Raghavan

Hi Hari
Its basically degenerated index. You can follow the below steps
1. Delete some entries from RSBERRORLOG.
BI database growing at 1 Gb per day while no data update on ECC
2. Re-organize this table from BRSPACE . Now the size of the table would be very less. I do not remember if this table has a LONG RAW field ( in that case export /import) of this table would be required. ---Basis job
3. Delete and recreate Index on this table
You will gain lot of space.
I assumed you are on Oracle.
More information on reoganization is LINK: [Reorg|TABLE SPACE REORGANIZATION !! QUICK EXPERT INPUTS;
Anindya
Regards
Anindya

Oracle 8.1.7.4 에서 reorganization 에 관한 질문입니다.

oracle 8.1.7.4 ops 에서 reorg작업을 할 생각입니다.
1) Database Offline Full backup
2) Table Reorganization.
2-1)ALTER TABLE table_name MOVE ;
2-2)LONG type 의 Table 은 exp/imp작업.
3) ALTER INDEX index_name REBUILD;
4) ANALYZE TABLE table_name COMPUTE STATISTICS FOR TABLE FOR ALL COLUMNS FOR ALL INDEXES;
5) ANALYZE INDEX index_name COMPUTE STATISTICS;
위와 같은 방법으로 진행할 생각인데 이에 관련하여 질문있습니다.
현재 DB extent_management 가 DICTIONARY 방식으로 되어있습니다.
제가 알아본 바로는
기존의 Dictionary Management Tablespace하에서는 Fragmentation이 있어 재구성 이후에서 space의 비효율적인 사용이 생길 수 있다고 합니다.
1)이에 관련하여 딕션너리 방식에서의 재구성 작업이 과연 의미가 있는지 궁금합니다.
2)그럼 딕션너리 방식에서 Locally로 바꾼후 재구성작업을 해야하는지도 궁금합니다.
3)또한 재구성에 관련하여 잘못된점이나 참고할 수 있는 문서 혹은 작업진행에 관련하여 답변부탁드립니다.

예전에 질문하신 내용이지만, 답을 주신 분이 없어 댓글을 달아봅니다.
세옹지마님이, tuning주제에 대한 토의에서도 설명하셨듯이, reorg는 중요합니다. 특히 다량의 데이타가 지워지거나 변경된 경우 그렇죠. (변경의 경우, index입장에서는 delete후 insert와 동일한 효과가 나타나니까요)
reorg는 index의 경우 데이타가 지워져서 빈공간이 많더라도 ordering이 유지되지 못하면 해당 block에 새로 입력되는 데이타가 들어가지 못하니, 일반적으로 table보다 더 필요하게 여겨지고,
table의 경우에도 fulll table scan의 경우 data가 있는 block만 읽는게 아니고 high water mark까지는 다 읽기 때문에 0건의 데이타를 읽기위해 10분의 select count(*) 작업을 하는 경우도 본만큼, 여전히 reorg가 필요합니다.
이러한 reorg는 locally-managed는 필요하고, dictionary managed는 불필요하다는건 잘못 들으신 내용 같습니다. 특히 locally managed tablespace의 경우 9i부터 제공되는 featue이고, 질문하신 분의 경우 8i를 사용하고 계시니 tablespace를 locally managed로 변경하실 수 없습니다.
이미 reorg하여 잘 사용하고 계시겠지만,
table의 대량의 삭제가 변경작업이 발생한 경우, 혹은 꾸준히 그러한 작업이 발생하여 주기적으로 reorg가 필요하다고 판단되는 경우.. dictionary managed tablespace라도 작업이 필요합니다 ~

DB6CONV/DB6 - Is there a way to reuse existing compression dictionary

As some of you probably know, DB6CONV handles compression by retaining the Compression flag while performing the table move , but unfortunately not the compression dictionary. This is causing some issues for tables to increase in size because of the way new dictionary gets built based on sample 1000 rows. Please see an example below where the Data Size of a compressed table increased after the tablemove.
For table SAPR3. /BI0/ACCA_O0900, please see the below statistics.
Old Table:
Data Size = 10,423,576 KB
Index Size = 9,623,776 KB
New Table (both data and index) with Index Compression (Moved using DB6CONV, took 1 hr for 100 million row table):
Data Size = 16,352,352 KB
Index Size = 4,683,296 KB
Reorg table with reset dictionary (By DB2 CLP takes 1hr and 32 Min)
Data Size = 8,823,776 KB
Index Size = 4,677,792 KB
We are on DB2 9.5 and will soon be migrating to DB2 9.7. In order to use the reclaimable table space feature that comes with DB2 9.7, We are planning on creating new tablespaces ( especially for objects like PSA/Change logs in BW) and then move the compressed tables after enabling index compression, but the DB6CONV is not going to be the right tool based on our experience.
Is there a way for DB6CONV or DB2 to reuse an existing compressed dictionary of the source table and reuse it when it performs a table move to a new tablespace.
Thanks,
Raja

hi raja,
no, DB6CONV cannot reuse the existing compression dictionary - this is in general not possible.
BUT: the good news is, that the next version V5 of DB6CONV will (amongst other new features) handle compression in a much better way! like R3load and online_table_move the compression dictionary will then be created based on (if possible) 20MB of sampled data ensuring optimal compression.
this new version will become generally available within the next few weeks.
regards, frank

SAP DB2 Deep Compression

Hi All
I need some help with IBM DB2 version 9.5 to implement deep compression on very large tables compressing all the data in the tables not just from the point of enabling the compression going forward, the problem is these tables are very bit one as large as 2TB, which will take to long to REORG.
I came across the IBM DB2 Deep Compression best practice guide which describes a method of creating a 10% sample table using the BERNOULLI function in a new table space, then activating the compression flag on this smaller table, running a REORG on the smaller table to generate the compression dictionary, and then to migrate all the data in the original table to the smaller table thus compressing the full content using the compression dictionary created off the 10% sample size and renaming the table names.
Code example in the guide looks like this:
CREATE TABLE T2 LIKE T1 IN TABLESPACE_B;
DECLARE LOAD_CUR1 CURSOR FOR SELECT * FROM T1 TABLESAMPLE BERNOULLI(10);
LOAD FROM LOAD_CUR1 OF CURSOR INSERT INTO T2;
REORG TABLE T2 RESETDICTIONARY;
DECLARE LOAD_CUR2 CURSOR FOR SELECT * FROM T1;
LOAD FROM LOAD_CUR2 OF CURSOR REPLACE INTO T2;
I would like to know if this is supported by SAP and if so how to handle the indexes and index table spaces linked to the data tables and data table spaces.
I used the SAP DB2 Compression Tool in SAP Note 980067 to identify the candidates for compression but the tables identified are the very big ones.
If you have any creative idea's I will be grateful for the help.
Thanks and regards,

Hello Amanda,
as far as I know, Deep Compression is supported by any SAP System that supports DB2 version 9.1 and higher. This should be supported from SAP kernel level 6.40 (SP18) upwards. But have a look at the SAP notes 900487, 1089568 or 1351160, depending on the DB2 version. Have also a look at [this page|http://www.sdn.sap.com/irj/scn/weblogs;jsessionid=%28J2EE3417800%29ID0062928350DB00623116135828352293End?blog=/pub/wlg/4330].
Compression can save lots of storage depending on your workload. It also improves I/O performance because not that much data must be moved over network. The only disadvantage known to me is that some extent of extra-CPU is needed to compress and recompress data.
Regards,
Marcel

Database Reorganize

Hi expert
I want to minimize the size of our current production server, so I delete 1 client (unused client)
Now I'm going to do database reorganization with BRTOOLS
my question is what table to reorganize ?
thanks
Della

Hi,
If you have delete the client than you have to go for full DB reorg (As suggest by Jaun). I am giving you some idea , how we can reorg DB with BRtolls.
If you go through the SAP Note which has mention by Jaun,than you can find that in oracle 10g we can reorg full DB online.
1:- Reorg Table which do not have LONG field
2:- Convert Long field to LOB field & Reorg Table which have LONG field .
If you need detailed DB reorg steps than go throug the below link.
[I have given detailed steps here|Re: Table reorganization]
Thanks & Regards
Gopal Kaushik

Oracle database reorganization (moving datafiles to new filesystems)

Hi All,
We are planning to perform a database reorganization (moving datafiles to new filesystems) in our Production environment using SAPDBA.
We had noticed in our recent performance reports that few datafiles in some of the SAPDATAxx filesystems are having higher I/O contention and are putting heavy load on those filesystems resulting in poor performance. So, we had identified the datafiles and planning to move them to new SAPDATA filesystems (uniformly distribute the datafiles to stabilize the I/O). Below are the version information.
SAP: 3.0F
Oracle: 9.2.0.8
OS: HP-UX 11.23
SAPDBA: 6.20
I'm going through SAP notes and Oracle documentation on this.Can you please share your experiences if similar activity was carried out by any of you and the documents relating to this.
Your inputs on this is very much appreciated.
Thanks,
Vasu

If your goal is just to make use of new storage, it is fairly straightforward and quick to move the datafiles as others mentioned. However, moving the datafile will NOT reorganize tables/tablespaces.
You can optionally reorg tables/tablespaces in addition to the move of datafiles. This generally saves space and helps performance. If you decide to reorg, I would suggest you move the datafiles to faster storage then reorg (since reorg itself is highly IO intensive).
Some points to consider:
- perform the reorg when business use is least
- perform online reorg where possible
- online reorg creates temporary snaps, typically in the users default tablespace, make sure it has sufficient space
- start with small tables/tablespaces first to get throughput estimate and also estimate of reduction in size
- estimate the size of target tablespace (how small it is going to be compared to source) and build the target tablespace smaller to avoid wasting space
- watch the space usage of the target tablespace when the reorg is running
- if you are reorging individual tables, make sure the indexes are rebuilt
Hope this helps.
Regards,
Shan

What command will be executed when I schedule job via DB13

Hi all,
How do I get what command(full syntax) will be executed when I schedule jobs via DB13?
For example:
- Action: REORG of Tables in Tablespace(s)
- Tablespaces: "WI6#BTABD" is selected
- "Use Temporary Tablespaces" is selected
I think this is a really basic question...
Could you give me some advice?
Thanks in advance,
Ikue

Hi Ikue,
yes, you won't see, what the 'REORG for all tablespaces is doing. But it's not really necessary. Its's simply always the same call
REORG TABLE <tabname> INDEX <primary key> ALLOW NO ACCESS
and optionally the addition USE <tempspace>, if you have selected this option in DB13. And it is called for each table that is located in the tablespace(s) which you have specified.
The 'REORG for set of tables' is quite new. It is available with Basis Support Package 7.0 SP12. Before there was only a job to Reorg a single table.
The REORG for flagged tables is a deprecated job.
If you want to know more about the various REORG jobs and when and how to use them, then you should look at note 431430
Best regards
Ralf

Converting TableSpace : Normal to Large

Hello,
I have a SAP R/3 470 - DB2 9.5. A few years ago was migrated from DB2 8.2 to 9.5, but Tablespace not been converted to LARGE.
Today I have one Tablespace (PRD#BTABD) that is near the limit of growth (64GB).
I have the following questions:
1 - What are the steps to convert only that Tablespace? Can I convert one tablespace only?
2 - I need to organize indexes and tables afterward? How to do this?
3 - I have three environments: DEV - QAS and PRD. Converting only Tablespace PRD#BTABD in the environment PRD, could have problems with transport requests or client copy?
thanks

Hi Johannes ,
So to avoid the SQL1236N scenario, first I convert the Tablespaces PRD#BATABD and PRD#BTABI and then run reorg on all tables of these tablespaces.
Running reorg these tablespace is already rearranging the indices. OK?
I'm following the procedures of the link http://www.ibm.com/developerworks/data/library/techarticle/dm-0702nesiem/
Q. Do I need to run the REORG INDEXES first and then REORG TABLE?
A. The table REORG performs the reorganization of the data and the indexes on the table. An index REORG is not required after this action. Bear in mind the table REORG That takes more time and must be Performed offline. An index REORG Might be sufficient depending on the expected growth of the table
doubt:
Since I convert the Tablespace PRD#BTABD and PRD#BTABI and run reorg on tables these tablespaces, I do not need to convert all the other SAP tablespaces. OK?
tks

Most allocated extents in any segment 6836

Hi all,
I have read a lot about reorg tables but the problem I have is that the tablespace causing us problems is SYSTEM.
Extents Owner Segment name Segm.type Tablespace
9,718 SYS C_OBJ#_INTCOL# CLUSTER SYSTEM
We are running Oracle 10.2.0.4.0 on BI7 EHP1
SYSTEM tablespace has Extent Management set to DICTIONARY all the others are LOCAL.
How do I go about solving this? I'm new to SAP BASIS work and I am no DBA.
Thanks
Craig

Hi Craig,
I do not have any guide on this.
For additional reference you may look into SAP help.
Recreating a Database with BR*Tools (SAP Library - SAP Database Guide: Oracle (BC-DB-ORA-DBA))
Recreate Database (SAP Library - SAP Database Guide: Oracle (BC-DB-ORA-DBA))
As per SAP note 748434
Logically, this results in the SYSTEM tablespace being "reorganized". The UNDO and TEMP tablespaces are also recreated in this case. However, no SAP data (series) is moved and only the SAP tablespaces (metadata) are exported and imported
Note 2:
Although no SAP data is exported or imported during the process, it is very time consuming and can take several hours.
Note 3:
Perform a complete database backup (preferably offline) before you begin the reconstruction. If the BRSPACE run terminates, the process cannot continue, and you must reset the entire database (with the "reset" function of BRRECOVER, for example).
Keep above points in mind before you execute dbcreate. Test this process on test environment first to estimate the time take and issues (if any).
Hope this helps.
Regards,
Deepak Kori

Reorg tables in 8.1.7

Similar Messages

Maybe you are looking for