Estimate index size on a table column before creating it
Hi
Is it possible to estimate the size of the index before actually creating it on a table column.
I tried the below query. It gives size of the index after creating it.
SELECT (SUM(bytes)/1048576)/1024 Gigs, segment_name
FROM user_extents
WHERE segment_name = 'IDX_NAME'
GROUP BY segment_name.
Can anyone through some light which system table will give this information.
You can get an approximation by estimating the number of rows to be indexes, the average column lengths of the columns in the index, and the overheads for an index entry - once you have some reasonable stats on the table.
I wrote a piece of code to demonstrate the method a few years ago - it's got some errors, but I've highlighted them in an update to the note: http://www.jlcomp.demon.co.uk/index_efficiency_2.html
Regards
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan
Similar Messages
-
How to estimate the size of the database object, before creating it?
A typical question arise in mind.
As DBA's, we all known to determine the objects size from the database.
But before creating an object(s) in database or in a schema, we'll do an analysis on object(s) size in relation with data growth. i.e. the size we are estimating for the object(s) we are about to create.
for example,
Create table Test1 (Id Number, Name Varchar2(25), Gender Char(2), DOB Date, Salary Number(7));
A table is created.
Now what is the maximum size of a record for this table. i.e. maximum row length for one record. And How we are estimating this.
Please help me on this...To estimate a table size before you create it you can do the following. For each variable character column try to figure out the average size of the data. Say on average the name will be 20 out of the allowed 25 characters. Add 7 for each date column. For numbers
p = number of digits in value
s = 0 for positive number and 1 for a negative number
round((( length((p) + s) / 2)) + 1
Now add one byte for the null indicator for each colmn plus 3 bytes for the row header. This is your row length.
Multiply by the expected number of rows to get a rough size which you need to adjust for the pctfree factor that will be used in each block and block overhead. With an 8K Oracle block size if you the default pctfree of 10 then you lose 892 bytes of storage. So 8192 - 819 - 108 estimated overhead = 7265 usable. Now divide 7265 by the average row length to get an estimate of the number of rows that will fit in this space and reduce the number of usable bytes by 2 bytes for each row. This is your new usable space.
So number of rows X estimate row length divided by usable block space in blocks. Convert to Megabytes or Gigabytes as desired.
HTH -- Mark D Powell --
ed add "number of usable" -
Index size increases than table size
Hi All,
Let me know what are the possible reasons for index size greater than the table size and in some cases index size smaller than table size . ASAP
Thanks in advance
sheriefhi,
The size of a index depends how inserts and deletes occur.
With sequential indexes, when records are deleted randomly the space will not be reused as all inserts are in the leading leaf block.
When all the records in a leaf blocks have been deleted then leaf block is freed (put on index freelist) for reuse reducing the overall percentage of free space.
This means that if you are deleting aged sequence records at the same rate as you are inserting, then the number of leaf blocks will stay approx constant with a constant low percentage of free space. In this case it is most probably hardly ever worth rebuilding the index.
With records being deleted randomly then, the inefficiency of the index depends on how the index is used.
If numerous full index (or range) scans are being done then it should be re-built to reduce the leaf blocks read. This should be done before it significantly affects the performance of the system.
If index access’s are being done then it only needs to be rebuilt to stop the branch depth increasing or to recover the unused space
here is a exemple how index size can become larger than table size:
Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
Connected as admin
SQL> create table rich as select rownum c1,'Verde' c2 from all_objects;
Table created
SQL> create index rich_i on rich(c1);
Index created
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 1179648 144 9
INDEX 1179648 144 9
SQL> delete from rich where mod(c1,2)=0;
29475 rows deleted
SQL> commit;
Commit complete
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 1179648 144 9
INDEX 1179648 144 9
SQL> insert into rich select rownum+100000, 'qq' from all_objects;
58952 rows inserted
SQL> commit;
Commit complete
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 1703936 208 13
INDEX 2097152 256 16
SQL> insert into rich select rownum+200000, 'aa' from all_objects;
58952 rows inserted
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 2752512 336 21
INDEX 3014656 368 23
SQL> delete from rich where mod(c1,2)=0;
58952 rows deleted
SQL> commit;
Commit complete
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 2752512 336 21
INDEX 3014656 368 23
SQL> insert into rich select rownum+300000, 'hh' from all_objects;
58952 rows inserted
SQL> commit;
Commit complete
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 3014656 368 23
INDEX 4063232 496 31
SQL> alter index rich_i rebuild;
Index altered
SQL> select segment_type,bytes,blocks,extents from user_segments where segment_name like 'RICH%';
SEGMENT_TYPE BYTES BLOCKS EXTENTS
TABLE 3014656 368 23
INDEX 2752512 336 21
SQL> -
Getting same index size despite different table size
Hello,
this question arose from a different thread, but touches a different problem, which is why I have decided to post it as a separate thread.
I have several tables of 3D points.
The points roughly describe the same area but in different densities, which means the tables are of different sizes. The smallest contains around 3million entries and the largest around 37 million entries.
I applied an index with
CREATE INDEX <index name>
ON <table name>(<column name>)
INDEXTYPE is MDSYS.SPATIAL_INDEX
PARAMETERS('sdo_indx_dims=3');
My problem is that I am trying to see how much space the index occupies for each table.
I used the following syntax to get the answer to this:
SELECT usim.sdo_index_name segment_name, bytes/1024/1024 segment_size_mb
FROM user_segments us, user_sdo_index_metadata usim
WHERE usim.SDO_INDEX_NAME = <spatial index name>
AND us.segment_name = usim.SDO_INDEX_TABLE;
(thanks Reggie for supplying the sql)
Now, the curious thing is that in all cases, I get the answer
SEGMENT_NAME SEGMENT_SIZE_MB
LIDAR_POINTS109_IDX .0625
(obviously with a different sement name in each case).
I tried to see what an estimated index size would be with
SDO_TUNE.ESTIMATE_RTREE_INDEX_SIZE
And I get estimates ranging from 230MB in the case of 3million records up to 2.9 for the case of 37million records.
Does anyone have an idea why I am not getting a different actual index size for the different tables?
Any help is greatly appreciated!!!
Cheers,
F.It looks like your indexes didn't actually create properly. Spatial indexes are a bit different to 'normal' indexes in this regard. A BTree index will either create or not. However, when creating a spatial index, something may fail, but the index structure will remain and it will appear to be valid according to the data dictionary.
Consider the following example in which the SRID has a problem:
SQL> CREATE TABLE INDEX_TEST (
2 ID NUMBER PRIMARY KEY,
3 GEOMETRY SDO_GEOMETRY);
Table created.
SQL>
SQL> INSERT INTO INDEX_TEST (ID, GEOMETRY) VALUES (1,
2 SDO_GEOMETRY(2001, 99999, SDO_POINT_TYPE(569278.141, 836920.735, NULL), NULL, NULL)
3
SQL> INSERT INTO user_sdo_geom_metadata VALUES ('INDEX_TEST','GEOMETRY',
2 MDSYS.SDO_DIM_ARRAY(
3 MDSYS.SDO_DIM_ELEMENT('X',0, 1000, 0.0005),
4 MDSYS.SDO_DIM_ELEMENT('Y',0, 1000, 0.0005)
5 ), 88888);
1 row created.
SQL>
SQL> CREATE INDEX INDEX_TEST_SPIND ON INDEX_TEST(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
CREATE INDEX INDEX_TEST_SPIND ON INDEX_TEST(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13249: SRID 88888 does not exist in MDSYS.CS_SRS table
ORA-29400: data cartridge error
Error - OCI_NODATA
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10
SQL> SELECT usim.sdo_index_name segment_name, bytes/1024/1024 segment_size_mb,
2 usim.sdo_index_status
2 FROM user_segments us, user_sdo_index_metadata usim
3 WHERE usim.SDO_INDEX_NAME = 'INDEX_TEST_SPIND'
4 AND us.segment_name = usim.SDO_INDEX_TABLE;
SEGMENT_NAME SEGMENT_SIZE_MB SDO_INDEX_STATUS
INDEX_TEST_SPIND .0625 VALID
1 row selected.
SQL>When you ran the CREATE INDEX statement did it say "Index created." afterwards or did you get an error?
Did you run the CREATE INDEX statement in SQL*Plus yourself or was it run by some software?
I suggest you drop the indexes and try creating them again. Watch out for any errors. Chances are its an SRID issue. -
Index size greater than table size
HI ,
While checking the large segments , I came to know that index HZ_PARAM_TAB_N1 is larger than table HZ_PARAM_TAB . I think it's highly fragmented and requires defragmentation . Need your suggestion on the same that how can I collect more information on the same . Providing you more information .
1.
select sum(bytes)/1024/1024/1024,segment_name from dba_segments group by segment_name having sum(bytes)/1024/1024/1024 > 1 order by 1 desc;
SUM(BYTES)/1024/1024/1024 SEGMENT_NAME
81.2941895 HZ_PARAM_TAB_N1
72.1064453 SYS_LOB0000066009C00004$$
52.7703857 HZ_PARAM_TAB
2. Index code
<pre>
COLUMN_NAME COLUMN_POSITION
ITEM_KEY 1
PARAM_NAME 2
</pre>
Regards
RahulHi ,
Thanks . I know that rebuild will defragment it . But as I'm on my new site , I was looking for some more supporting information before drafting the mail on the same that it requires re org activity .It's not possible for an index to have the size greater than tables as it contains only 2 columns values + rowid . Whereas tables contains 6 columns .
<pre>
Name Datatype Length Mandatory Comments
ITEM_KEY VARCHAR2 (240) Yes Unique identifier for the event raised
PARAM_NAME VARCHAR2 (2000) Yes Name of the parameter
PARAM_CHAR VARCHAR2 (4000)
Value of the parameter only if its data type is VARCHAR2.
PARAM_NUM NUMBER
Value of the parameter only if its data type is NUM.
PARAM_DATE DATE
Value of the parameter only if its data type is DATE.
PARAM_INDICATOR VARCHAR2 (3) Yes Indicates if the parameter contains existing, new or >replacement values. OLD values currently exist. NEW values create initial values or replace existing values.</pre>
Regds
Rahul -
Index size bigger than table name? why?
I have a table student_enrollwment_item_tbl with primary key "pk_stu_enroll_item" - STU_ENROLL_ID, TASK_ID, PART_ID, ITEM_ID.
Table structure is as following:
Name Null? Type
STU_ENROLL_ID NOT NULL NUMBER
ITEM_ID NOT NULL VARCHAR2(15)
PART_ID NOT NULL NUMBER(2)
TASK_ID NOT NULL VARCHAR2(10)
QUESTION_NO NOT NULL VARCHAR2(25)
FLASH_NO NOT NULL NUMBER(3)
ITEM_NO NUMBER(3)
The table is 1856 MB in size, while the index is 2730 MB in size. I am surprised since 'size of index > size of table'. Why will it happen?1) As seen from the result of the following sql, the PCT_FREE is 10. It's not bad.
select index_name, table_name, ini_trans, max_trans, initial_extent, min_extents, max_extents,
freelists, freelist_groups, pct_free, leaf_blocks from all_indexes
where table_name = 'STUDENT_ENROLLMENT_ITEM_TBL';
INDEX_NAME TABLE_NAME INI_TRANS MAX_TRANS INITIAL_EXTENT MIN_EXTENTS MAX_EXTENTS FREELISTS FREELIST_GROUPS PCT_FREE LEAF_BLOCKS
pk_stu_enroll_item STUDENT_ENROLLMENT_ITEM_TBL 2 255 379125760 1 2147483645 1 1 10 323428
2) The pattern is like this:
I regards it as being not sequential, but with a lot of distinct values.
STU_ENROLL_ID ITEM_ID PART_ID TASK_ID QUESTION_NO FLASH_NO ITEM_NO
10005085 C31001008 1 C310010 8 9 8
10005085 C31001009 1 C310010 9 10 9
10005085 C31001010 1 C310010 10 11 10
10005086 0 0 C310010 0 0 0
10005086 0 1 C310010 0 1 0
10005086 C31001001 1 C310010 1 2 1
10005086 C31001002 1 C310010 2 3 2
10005086 C31001003 1 C310010 3 4 3
10005086 C31001004 1 C310010 4 5 4
10005086 C31001005 1 C310010 5 6 5
10005086 C31001006 1 C310010 6 7 6
10005086 C31001007 1 C310010 7 8 7
10005086 C31001008 1 C310010 8 9 8
10005086 C31001009 1 C310010 9 10 9
10005086 C31001010 1 C310010 10 11 10
10005055 C31001005 1 C310010 5 6 5
10005055 C31001006 1 C310010 6 7 6
10005055 C31001007 1 C310010 7 8 7
10005055 C31001008 1 C310010 8 9 8
3) Not many deletes have been ran in the table as I know.
I still cannot figure out the reason. Please help. Thanks. -
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,
RaghavanHi 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 -
Estimate db size and change tablespace configuration before restoring RMAN
Hi,
I am wondering whether it is possible to estimate the size of the restored database just from the RMAN files I have?
Also, Is there a setting I can change in these files to disable 'autoextend' feature in the tablespace of the restored database?
thank you in advance.Hi
But using this method I will damage the existing control file of the original server.
SQL 'alter database mount';
sql statement: alter database mount
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of sql command on default channel at 09/16/2009 17:18:59
RMAN-11003: failure during parse/execution of SQL statement: alter database mount
ORA-01103: database name 'OLD_DB' in control file is not 'JUPITER'
And when I start JUPITER:
startupORACLE instance started.
Total System Global Area 192937984 bytes
Fixed Size 2169752 bytes
Variable Size 134079592 bytes
Database Buffers 54525952 bytes
Redo Buffers 2162688 bytes
ORA-00205: error in identifying control file, check alert log for more info
Is there a way to restore the control file without damaging the existing server?
thank you for your support. -
TABLE SIZE 및 INDEX SIZE(크기) 계산
제품 : ORACLE SERVER
작성날짜 : 2002-10-15
TABLE SIZE 및 INDEX SIZE(크기) 계산
===================================
1. TABLE SIZE 계산 공식(ORACLE BLOCK SIZE : 2K 로 가정)
$ sqlplus scott/tiger
SQL> SELECT GREATEST(4, ceil(ROW_COUNT /
((round(((1958 - (initrans * 23)) *
((100 - PCTFREE) /100)) / ADJ_ROW_SIZE)))) * BLOCK_SIZE)
TableSize_Kbytes
FROM dual;
*. 한 개의 BLOCK에 Available 한 Bytes - 1958
*. 각 initrans 는 23 Bytes
*. PCT_FREE : Table 의 pctfree 값(default 10)
*. ADJ_ROW_SIZE : 각 row 의 평균 SIZE 추정치
*. ROW_COUNT : table 의 row 의 갯수
*. BLOCK_SIZE : 1 block의 크기 (단위: K)
예) table 이름이 EMP 일 경우
ROW_COUNT : select count(*) from emp;
ADJ_ROW_SIZE :
analyze table emp compute statistics;
(또는 건수가 매우 많을 때에는 compute 대신 estimate 사용)
select avg_row_len
from user_tables
where table_name='EMP';
2. INDEX SIZE 계산 공식
SQL> SELECT GREATEST(4, (1.01) * ((ROW_COUNT /
((floor(((2048 - 113 - (initrans * 23)) *
(1 - (PCTFREE/100))) /
((10 + uniqueness) + number_col_index +
(total_col_length)))))) * DB_BLOCK_SIZE))
IndexSize_Kbytes
FROM dual;
*. 한 개의 block에 available 한 bytes ( 1935 or 2048 - 113 )
*. 각 initrans 는 23 Bytes
*. ROW_COUNT : table 의 row 의 갯수
*. PCTFREE : Index 의 pctfree 값(default 10)
*. number_col_index : Index 에서 column 의 수
*. total_col_length : Index 의 길이 추정치
*. uniqueness : 만일 unique index 이면 1, non-unique index 이면 0.
*. DB_BLOCK_SIZE : 1 block의 크기 (단위: K)데이터블록 레이아웃을 보면..
Data Block Layout
Block header에는 cache layer와 Transaction layer을 가지고 있습니다.
Data layer에는 Table directory, Row directory, Free space, Row data
이렇게 나누어지구요..
v$type_size를 보면.. KCB와 KTB의 크기가 실제로 헤더의 크기입니다.
여기서는 92로 계산되었는데..
2048-92=1956 으로 나옵니다.
여기서의 값이 아닐지요? 2바이트가 차이나긴 하군요.;
COMPONENT TYPE DESCRIPTION TYPE_SIZE
KCB KCBH BLOCK COMMON HEADER 20
KTB KTBIT TRANSACTION VARIABLE HEADER 24
KTB KTBBH TRANSACTION FIXED HEADER 48 -
What table column size is needed to accomodate Unicode characters
Hi guys,
I have encounter something which i dont understand and i hope gurus here will shed some light on me.
I am running a non-unicode database and i decided to port the data over to a unicode database.
So
1) i export the schema out --> data.dmp
2) then i create the unicode database + create a user
3) then i import the schema into the database
during the imp i can see that character conversion will take place.
During importing of data into the unicode database
I encounter some error
saying column size is too small
so i went to check the row that has the column value that is too large to fit in the table.
I realise it has some [][][][] data.. so i went to the live non-unicode database and find the row. Indeed it has some [][][][] rubbish data which i feel that someone has inserted other language then english into the database.
But regardless,
I went to modify the column size to a larger size, now the row can be accommodated. However the data is still [][][].
q1) why so ? since now my database is unicode, during the import, this column data [][][] should be converted to unicode already but i still have problem seeing what language it is.
q2) why at the non-unicode database, the [][][] data can fit into the table column size, but on unicode database, the same table column size need to be increase ?
q3) while doing more research on unicode, it was said that unicode character takes up 2 byte per character. Alot of my table data are exactly the same size of the table column size.
E.g Name VARCHAR2(5);
value - 'Peter'
Now if converting to unicode, characters will take 2byte instead of 1, isnt 'PETER' going to take up 10byte ( 2 byte per character ),
why is it that i can still accomodate the data into the table column ?
q4) now with unicode database up, i will be supporting different language characters around the world. How big should i set my column size to ? the longest a name can get ? or ?
Thanks guys!/// does oracle automatically "look" at the each and individual characters in a word and determine how much byte it should take.
Characters usually originate from a keyboard, which has an associated keyboard layout and an associated character set encoding (a.k.a code page, a.k.a. encoding). This means, the keyboard driver knows that when a key with a letter "á" on it is pressed on a French keyboard, and the associated character set encoding is MS Code Page 1252 (Oracle name WE8MSWIN1252), then one byte with the value 225 is generated. If the associated character set encoding is UTF-16LE (standard internal Windows encoding), two bytes 225 and 0 are generated. When the generated bytes travel through APIs, they may undergo character set conversions from one encoding to another encoding. The conversion algorithms use translation tables to find out how to translate given byte sequence from one encoding to another encoding. In case of translation from WE8MSWIN1252 to AL32UTF8, Oracle will know that the byte sequence resulting from conversion of the code 225 should be 195 followed by 161. For a Chinese characters, for example when converting it from ZHS16GBK, Oracle knows the resulting sequence as well, and this sequence is usually 3 bytes.
This is how AL32UTF8 data gets into a database. Now, when Oracle processes a multibyte string, and needs to look at individual characters, for example to count them with LENGTH, or take a substring with SUBSTR, it uses information it has about the structure of the character set. Multibyte character sets are of two type: fixed-width and variable-width. Currently, Oracle supports only one fixed-width multibyte character set in the database: AL16UTF16, which is Oracle's name for Unicode UTF-16BE encoding. It supports this character set for NCHAR/NVARCHAR2/NCLOB data types only. This character set uses two bytes per each character code. To find the next code, 2 is simply added to the string pointer.
All other Oracle multibyte character sets are variable-width character sets, including AL32UTF8. In most cases, the length of each character code can be determined by looking at its first byte. In AL32UTF8, the number of 1-bits in the most significant positions in the first byte before the first 0-bit tells how many bytes a character has. 0 such bits means 1 byte (such codes are identical to 7-bit ASCII), 2 such bits mean two bytes, 3 bits mean 3 bytes, 4 bits mean four bytes. 1 bit (e.g. the bit sequence 10) starts each second, third or fourth byte of a code.
In other ASCII-based multibyte character sets, the number of bytes is usually determined by the value range of the first byte. Bytes below 128 means a one-byte code, bytes above 128 begin a two- or three-byte sequence, depending on the range.
There are also EBCDIC-based (mainframe) multibyte character sets, a.k.a shift-sensitive character sets, where a sequence of two-byte codes is introduced by inserting the SO character (code 14=0x0e) and ended by inserting the SI character (code 15=0x0f). There are also character sets, like ISO-2022-JP, which use more complicated byte sequences to define the length and meaning of byte sequences but Oracle supports them only in limited number of places.
/// e.g i have a word with 4 character. the 3rd character will be a chinese character..the rest are ascii character
/// will oracle use 4 byte per character regardless its ascii(english) or chinese
No.
/// or it will use 1 byte per english character then 3 byte for the chinese character ? e.g.total - 6 bytes taken
It will use 6 bytes.
Thnx,
Sergiusz -
Table index size in DB02 smaller after upgrade
SAP ERP 6.0, DB2 9.5, AIX 5.3. After we upgraded to SPS 15 / EHP4 / Netweaver EHP1 SPS02 using the downtime minimized method (shadow instance created) the index sizes for the tables are showing reduced sizes. When looking in DB02 under History -> "tables and indexes" all the tables show a drop in index sizes. I have compared the indexes to a pre upgrade copy of the system and all the indexes are still defined and active in the upgrades system. Can somebody please explain why the size drop? Is this a reporting error or what?
Hi Eddie,
DB2 V8.2 did not allow to retrieve table/index size information from DB2 directly. Therefore the SAP DB2 database interface and the CCMS code tried to do some size estimation based on cardinality and table/index width. DB2 V9.1+ provides table function ADMIN_GET_TAB_INFO to retrieve size information directly from DB2. Since this size information is much more accurate the SAP DB2 database interface and the CCMS code have been changed to use this table function.
So the phantom-"shrink" you observed may be related to the switch from size estimation to the size retrieved from ADMIN_GET_TAB_INFO . This may have happened directly after the V9.5 upgrade ( size retrieved differently in SAP DB2 database interface ) or after the SAP release upgrade ( change in CCMS ABAP coding ).
Regards
Frank -
We are planning to use Oracle database (Oracle 10g in Unix). We are in the process of estimating the hard disk capacity(in GB) required based on the past data for each business process. But we are faced with following queries
1. Assuming the structure for a table is as follows :-
create table temp1(
Name varchar2(4),
Age Number(2),
Salary Number(8,2),
DOB Date)
The estimated records per year is assumed to be 500. How can we estimate the size that will be required for this table.
2. We are planning to allocate 20% space for indexes on each table. Is it ok?
3. Audit Logs (to keep track of changes made through update) :- Should it be kept in different partition/hard disk?
Is there anything else to consider. Is there a better way to estimate the hard disk capacity required in more accurate manner?
Our current database in Informix takes around 100GB per year, but there r lot of redundant data and due to business process change we cannot take that into consideration.
Kindly guide. Thanks in advance.Well you can estimate the size of a table by estimating the average row size then multiplying this by the expected number of rows then add in overhead.
3 for the row header + 4 for name + 2 for age + 5 for Salary + 7 for a date + 1 for each column null/length indicator is about 25 bytes per row (single byte character set) * 500 rows * 1.20 (20% overhead) = small.
The overhead is the fixed block header, the ITL, the row table (2 bytes per row) and the pctfree. You can estimate this but I just said 20% which is probably a little high.
The total space needed by indexes often equals or surpassed the space needed by tables. You need to know the design and be pretty sure additional indexes will not be necessary for performance reasons before you allocate such a small percentage of the table space to index space.
Where you keep audit tables or extracts is totally dependent on your disk setup.
HTH -- Mark D Powell -- -
Hi All,
I have two table with similar structure and data, one is on disk and the other is in memory. I somehow calculated the difference between a row size of on disk and in memory table and found that the row size of in memory is 700 Bytes more than the disk based
tables.
aaAs others mentioned, memory optimized tables and disk based tables have different structures in SQL Server 2014.
For memory optimized tables, the number of indexes on table also contribute to the size. You can calculate the exact size of rows and thus the table size using the formula given in the below articles
Table and Row Size in Memory-Optimized Tables
Estimate the Size of a Table
Krishnakumar S -
Creating a bit map index on a partitioned table
Dear friends,
I am trying to create a bitmap index on a partitioned table but am receiving the following ORA error. Can you please let me know on how to create a local bit map index as the message suggests?
ERROR at line 1:
ORA-25122: Only LOCAL bitmap indexes are permitted on partitioned tables
Trying to use the keyword local in front leads to wrong syntax.
Thanks in advance !!
SomnathORA-25122 Only LOCAL bitmap indexes are permitted on partitioned tables
Cause: An attempt was made to create a global bitmap index on a partitioned table.
Action: Create a local bitmap index instead
Example of a Local Index Creation
CREATE INDEX employees_local_idx ON employees (employee_id) LOCAL;
Example is about btree and I think it will work for bitmap also. -
Table got re-created with 0 entries
Hello All,
In ECC system after refresh BDLS is taking too long time(24hrs to 36hrs) becase of that as per SDN blogs to improve BDLS performance i build the index on few tables mentioned below using SE11 & SE14 t-codes, after completing BDLS I dropped those indexes while dropping BKPF table got re created with 0 entries but other tables are having entries. i have followed sam eprocess for all the tables, after that i tried in sandbox system that system also while dropping BKPF got re-created with ' 0 'entries ,Could you please let me know why it has re-created with 0 entries.
BKPF
CE11000
COBK
COEP
COES
COFIS
GLPCA
GLPCP
GLPCT
MKPF
SRRELROLESThanks for the Prompt response,
The service entry was created this month
I did try by checking the "Deliv. Compl." indicator on the PO and then tried to reverse the service entry but I get the same error i.e SE541
Thanks
Maybe you are looking for
-
MIC not verified # authentication-failed
Hi, We are getting this error while trying to send messages from XI through AS2: MIC not verified # authentication-failed Can anybody please let us know the reason for this error. Thanks in advance. Best Regards, Shweta
-
My new CS5 suite, although successfully loaded, does not have an icon for InDesign. It's there; I'm using it by opening an existing file; but cannot create a shortcut to begin a new project. Any ideas?
-
Daniel SterchiHI i am user for InDesincc TrialVersion now. i have serious question for all guys in here. at first i installed Indesigncc as korean language but now i need to indesigncc english language installation. and then now i cant translate and
-
Photoshop Elements Save for Web
The default file type for this command is GIF. I never use GIF, I always use jpeg. This means I have to change it every time which is a nuisance. Is there a way to change the default from GIF to jpeg?
-
Why do temporary internet files show up as a tab?
Why are temporary internet files showing up as a tab in FF ver 8? I have the private browsing option on.