Server Administration :: Index Rebuild Grows Database Size
Oct 29, 2010
Our database size is 100GB and i removed few records from a table and rebuild the index.The size of Index reduced considerably after Index rebuild but now i see our database size increased to 115GB.I know online rebuild creates second index which is also removed after the build is finished then why the increase in database size?Is there a way so it shows up more space ?
select sum(bytes) from dba_segments where owner='abc' and segment_name='abc_index_1';
8GB
ALTER INDEX abc_index_1 REBUILD ONLINE ;
select sum(bytes) from dba_segments where owner='abc' and segment_name='abc_index_1';
2GB
We have separate tablespaces for Tables and Indexes. Also Temp is in different temporary tablespace and UNDO also in UNDO tablespace and Index tablespace contains only Indexes. The tablespace usage for tables is 80% and Index is 91%.There is not enough disk space to allocate for the datafile on our system. I ran a rebuild on one of the Index but now notice the Index tablespace is 98% used soon after the rebuild finished.
How can i free up space for Index tablespace and why does the size of Index tablespace increased after the rebuild.
I have Oracle 11gR2 running on windows xp machine. Windows xp has total size of 150 GB and free space of 95 GB.
I checked the size of the database that I created. It showed the total size of the database as 2 GB and used space as 2 GB. If I want to increase the total size of the database to 50 GB, what should i do? Now which is the disk space size? Windows or Oracle?
I have checked the space of my tablespaces/datafiles in my database. I have 8 GB space left in my database server. I cant add more hard-disk as there is no slot left. We r planning to buy a new server with latest config.
My question is, how can we know upto what size our database can increase and when a datafile need to be added in advance. Sometimes even though datafiles have space left,it shows errors abt extents cannot be extended. We have coalesce the tablespaces and added a new datafile.
I am storing customer's snaps in a table ( column's data type as LONG RAW) using oracle forms Webutil. Now there are 250 snaps in the table. The file type of these snaps is JPG with the average size 30KB.
I made a backup using export utility before storing these snaps and the exported DMP file's size was 36MB. Now after storing these just 250 snaps of 30KB the DMP file's size is gone over 300MB.
i need to change column's datatype? or some where in oracle forms's image item. Because on window's file system the size of these files is just 8MB.
i written this code i m facing ORA-04030: out of process memory when trying to allocate 16408 bytes error
/* Formatted on 2011/11/26 11:52 (Formatter Plus v4.8. */ DECLARE row_id varchar2(50); v_batch_id temp.batch_id%TYPE; v_slab_id temp.slab_id%TYPE; flag NUMBER (2); num varchar2(50) := &row_id;
We have a requirement from the customer to start using data and index compression in our 11g database.. Is this something available in Oracle 10g,11g without any additional costs? We are not sure if this will work with our application so we will have to test it in-house, is it possible to compress the existing table data/index to test it out?
We have Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production on AIX platform. We've noticed that the CPU usage on the server is slowly but steadily grows since instance restart: after the instance restart the maximum CPU usage is about 25-30%, and a month later with the comparable transactional load it's about 60-65%. In the top I see a lot of Oracle sessions each of which use about 1% of CPU, so I cannot find the one "CPU eater".
when trying to select * from dba_network_acls getting error massage Rowid invalid
ALTER INDEX CTXSYS.SYS_C003684 REBUILD; ALTER INDEX CTXSYS.SYS_C003683 REBUILD; ALTER INDEX CTXSYS.SYS_C003682 REBUILD; ALTER INDEX CTXSYS.SYS_C003681 REBUILD;
[code]...
It is possible to recreate this index again.......
oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production PL/SQL Release 11.1.0.6.0 - Production "CORE 11.1.0.6.0 Production"
I have a procedure that is run weekly to load the data, for which it calls another procedure. This weekly procedure, disables the index, load the data, and rebuilds the index. During rebuilding of index, its giving ORA-00054: resource busy and acquire with NOWAIT error. I dont have privileges to look for session id, and kill the session. How to avoid this error.
create or replace PROCEDURE "WCL_WEEKLY_UPLOAD" ( p_event_id IN NUMBER ) [code]....
As you can see, after the procedure wc_upload, COMMIT is issued, and then the rebuilding of the index is starting. So dont know what is causing the table to lock.
Index with following PARTITIONS. Index rebuild is extremely slow. Below 2 Alter index ..rebuild... took 10 hours to complete. Because of this queries which based on this index are really slow.
SYS@DB AS SYSDBA> select partition_name,tablespace_name,bytes/1024 KB from dba_segments where segment_name='KSTN'; PARTITION_NAME TABLESPACE_NAME KB ------------------------------ ------------------------------ ---------- REB_IDX_1 TS_REB 64 REB_IDX_2 TS_REB 64 REB_IDX_3 INDEX 64 REB_IDX_4 TS_REB 64
2day i was dropping few unwanted index from the data base, By mistake i removed the local partitioned index , So i want to recreate that index.i create the index, will the partitioned index updates when we add partitioned to the tables.
We have large tables 60-70 GB having 120 million records. We have to perform index rebuild frequently which takes significant time to complete and effects database performance too. how we can use index Coalesce? what are its benefits, coalesce results in performance gain?
I am rebuilding some UNUSABLE local index partitions on Oracle 8.1.7.4.0 (64bit) database . The platform is a HPUX machine.
The DDL of the partition table/indexes: ========================= CREATE TABLE TESTME ( INST_NO CHAR(3) NOT NULL, ACCT_NO CHAR(16) NOT NULL, REC_NO CHAR(9) NOT NULL, TRAN_TYPE CHAR(2) DEFAULT ' ', STAT CHAR(2) DEFAULT ' ', [code]...
