Reclaiming space in a database...

Hi
Would like to request your views on a scenario.
I have exported a database [Oracle version 9i or 10g] (using original exp) with rows=N. Now though there is no data but it still will occupy the same space because of the extent thing. Now I want to get rid of this & bring database back to its actual size (that is: what it should be without data).
Can you suggest some ways for that. I have done some RnD and found out few methods like import DB on some machine where there is free space. Then
Option 1: Create new tablespaces (of possible small size and with auto extend on) and move the objects to them. Rebuild indexes in new tablespace.
Option 2: Truncate tables so that HWM comes down.
Anything else you guys can suggest. Any tips n tricks are welcome.
Thanks
Sidhu

If you want to interfere with the space parameters in an export, the easiest way is to use the SHOW=Y option
imp user/password file=myexport.dmp show=Y
You'll see a series of DML statements. Each statement is broken up into lines so it looks something like this
"CREATE TABLE "TEST" ("DUMMY" NUMBER NOT NULL, "NAME" VARCHAR2(2"
"0), "DESCRIPTION" VARCHAR2(1000)) PCTFREE 10 PCTUSED 40 INITRAN"
"S 1 MAXTRANS 255 STORAGE(INITIAL 65536 FREELISTS 1 FREELIST GRO"
"UPS 1 BUFFER POOL DEFAULT) TABLESPACE "USER" LOGGING NOCOMPRESS"
. . skipping table "TEST"You can also use the indexfile=filename.sql option. Table create statements are included (but they are commented out). It's easy to write a shell script to reformat this, adjust tablespace names and sizes, etc.
(I have one at home I prepared earlier - not accessible right now)
HTH
Regards Nigel

Similar Messages

Reclaim space at OS level.

Dear all
I have performed following activities to reclaim space at database level on development system but I am quite suspicious about to reclaim at OS level.
1) Choose baldat table for REORG candidate
2) Size of table before deleting record was 11GB
3) Delete record from it using slg2
4) Offline REORG done
5) Table size is now around 2.5GB
6) Since database is DB9.7 and tablespace is in DMS type, I need to issue two command as following to reclaim space at DB and OS level.
     alter tablespace TCD#BTABD lower high water mark
     ALTER TABLESPACE TCD#BTABD REDUCE (ALL CONTAINERS G/K/M)
7) I have issued only first command to lower HWM which freed up space at Database level.
     Checked from DBACOKPIT to see tablespace status as following
     Tablespace Name     KB Total     Percent Used     KB Free     Page Size (KB)     High-Water Mark (KB)
     TCD#BTABD            16121856        33.25           10762016       16                         5359712
Now my query is I want to reduce it down by 9GB at OS level so which figure I have to put (??) on the following. Is there any harm to execute this command on the fly which causes database issue???
      ALTER TABLESPACE TCD#BTABD REDUCE (ALL CONTAINERS ??? G/K/M)
Thanks
Mehul

Hi,
I have a following output from abovemention query
TBSP_NAME                      TBSP_TYPE RECLAIMABLE_SPACE_ENABLED
SYSCATSPACE                    DMS                                1
SAPTOOLS                       DMS                                1
SAPEVENTMON                    DMS                                1
PSAPTEMP16                     SMS                                0
SYSTOOLSTMPSPACE               SMS                                0
SYSTOOLSPACE                   DMS                                1
TCD#STABD                      DMS                                1
TCD#STABI                      DMS                                1
TCD#BTABD                      DMS                                1
TCD#BTABI                      DMS                                1
TCD#CLUD                       DMS                                1
TCD#CLUI                       DMS                                1
TCD#POOLD                      DMS                                1
TCD#POOLI                      DMS                                1
TCD#DDICD                      DMS                                1
TCD#DDICI                      DMS                                1
TCD#DOCUD                      DMS                                1
TCD#DOCUI                      DMS                                1
TCD#EL702D                     DMS                                1
TCD#EL702I                     DMS                                1
TCD#LOADD                      DMS                                1
TCD#LOADI                      DMS                                1
TCD#PROTD                      DMS                                1
TCD#PROTI                      DMS                                1
TCD#ES702D                     DMS                                1
TCD#ES702I                     DMS                                1
TCD#SOURCED                    DMS                                1
TCD#SOURCEI                    DMS                                1
TCD#USER1D                     DMS                                1
TCD#USER1I                     DMS                                1
TCD#DIMD                       DMS                                1
TCD#DIMI                       DMS                                1
TCD#FACTD                      DMS                                1
TCD#FACTI                      DMS                                1
TCD#ODSD                       DMS                                1
TCD#ODSI                       DMS                                1
36 record(s) selected.
Thanks
Mehul

Reclaim space from DBFs

Hi All,
I have one query regarding tablespace reclaim space. I have users tablespace which is having 5 dbfs. Some of the DBFs of USERS tablespace having autoextend on with max size 32G and some of the DBFs not having autoextend on and maxsize 4G.
Now when I checked the USERS TBS through EM , I come to know only few MBs out of 20G are in used in 3 DBFs of USERS tablespace and rest of 2 dbfs are in good in use. Now I want to reclaim the space from 3 dbfs say users03,users04 and users05. users01 and users02 are properly in used. I want to reclaim the space from 03,04 and 05.
can I have any idea how to reclaim space from dbfs? I try with alter database datafile ...resize but giving error "ORA-03297: file contains used data beyond requested RESIZE value".
please suggest me,
Thanks...

Yes, I think you are understanding how it works. For a visual example, if this is your data file:
XXXX--XX-XXXX-XXXX-XXXX-XXXXXXX-----------------
and you delete some data
XX----X--------X------------------X-----------------
The datafile can be resized only down to
XX----X--------X------------------X
Which tools are available to do this efficiently vary by database version, for example in my 9.2.0.6 database I can use exp/imp, CREATE TABLE AS SELECT, rebuild indexes (mostly) online, exp/imp, move LOBs around with ALTER TABLE ... MOVE LOB, or other strategies - some of these are more work than others, and all will take some amount of time. In 8i There are fewer options; beginning with 10g data pump and DBMS_REDEFINITION are available; in 11g the index rebuilds don't lock the data, so the time may be less of a concern.
Before you even spend the time to shrink these data files, consider the space needs for USERS. If the extended size was a one-time thing, then shrinking datafiles may be justified. If USERS may grow that large again then a data file shrink is a lot of work for little gain.

Benefits of Reorg to reclaim space in Oracle

Hi All,
I have archived and deleted records from few big tables from my database, now how want to reclaim space by doing reorg.
Can anyone please guide me how to find out If I can reclaim some space by doing reorg.
What are the queries which can help me find out space used before and after reorg.
Thanks & Regards,
Deepak

You cannot do much with a long raw short of export/import it - so you would export it, drop the old table, create a new one in the new tablespace and import with ignore=y. Other objects can be online redefined into this tablespace - or indexes if they are in there can be rebuilt online into this new tablespace, but moving the long raw is going to be offline.
Source:Ask Tom &quot;Reclaim space&quot;
Shrink, Move, CTAS (Reclaiming space) do not works for LONG datatype. For LONG dataype export/import is the best and feasible solution.
Regards
Girish Sharma

Re-organizing table to reclaim space

Hi All,
Recently we have purged data from some tables in the database.
Is it necessary to reorganize the table to reclaim space after we remove the data from the tables? How can we find out that the table can be reorganized?
Database version:11.2.0.2
OS version:AIX

how did you purge the data?
have you used delete or truncate.
please check space under dba_segments for particular object which was purged.
from 10g onwards we have segment advisor.
The segment advisor performs analysis on the fragmentation of specified tablespaces, segments or objects and makes recommendations on how space can be reclaimed. The advisor is accessible from Enterprise Manager (Home > Advisor Central > Segment Advisor) or from PL/SQL by using the DBMS_ADVISOR package.
https://forums.oracle.com/forums/ann.jspa?annID=718
Please close the thread after marking it helpful or correct if you get the answer.
Thanks
Kuljeet Pal Singh

Query needed to find reclaimable space in db

10.2.0.4
Linux 4.
Hi.
On a test database I suspect there are a lot of objects that are not needed that are taking up valuable disk space. These may include tables that are backups of tables etc.
Does anyone have a tested query to seek out these objects? They will have probably been named test, or backup, etc.
Thanks in advance.

Apparently you want to find candidate junk objects to discard. This is a quite specific subset of the overall issue of finding reclaimable space. In the overall issue a lot of attention should be paid to whether temporarily supressing some free space (due to massive deletions, for example) is worthwhile. In the subset you inquire about, if you can identify the junk it is almost certainly a win to discard it. Some shops have naming standards for objects not officially sanctioned in the production schema. My favorite is the prefix JUNK_<initials>_, so that all the objects can be found quickly with the wildcard on the efficient end of the query, as in:
select owner,object_name,object_type
   from dba_objects
   where object_name like 'JUNK%'
   order by object_name;
or
select owner,object_name,object_type
   from dba_objects
   where object_name like 'JUNK_MWF%'
   order by object_name;Even just the naming convention makes it easy to identify candidate objects, and if you have rules about creating "JUNK" objects such as maintaining a log with expiration dates and purposes, then further inquiry is easy. Having the object's sponsor's initials at hand makes a personal interview possible if the log entries are not useful, and if an expiration date is provided you can simply use the log table as a list to control deleting discardable objects.
In your case you are dealing with catching the horses after the stalls and barn door were left open. Up to now I've written more about closing the barn door for future efforts.
For the cleanup, the similar query with the like predicate '%TEST' and other candidate name templates should suffice. Depending on how creative folks have been spelling TST and BCKUP, you may want to play with the regex functions. Just be sure to treat the generated list as a list of candidates. Depending on the length of the list you can then either generate the appropriate drop statement by type or simply type them into a file for review and execution. Sending out the list of objects to be deleted with a reasonable warning period is highly recommended, since having the ability to create unknown objects often implies sufficient rank to ignore organizational rules. Whether creating an individual object export prior to the drop will vary from site to site and by the size of the object to be dropped.
Good luck,
mwf (aka pudge)

Shrink / reclaim space

what is the best proceedure to reclaim or shrink a 109GB of reclaimable space? w/o using alot of disk space.
tyia

1. ALTER TABLE tablename SHRINK SPACE COMPACT;
-> DML operations and queries can be issued during compaction.
2. ALTER TABLE tablename SHRINK SPACE;
-> DML operations are blocked when the HWM is adjusted.
When you specify the SHRINK SPACE COMPACT clause, the progress of the shrink operation is saved in the bitmap blocks of the corresponding segment. This means that the next time a shrink operation is executed on the same segment, the Oracle database server remembers what has been done already. You can then reissue the SHRINK SPACE clause without the COMPACT clause during off-peak hours to complete the second phase.

Insufficient free space in the database during upgrademodule General checks

we are upgrading SAP R/3 Enterprise 470 110 to ECC6 on Oracle/Windows.
During PREPARE module: General checks the file CHECKS.LOG show the following information:
   #====================================================#
Requests and information for module General checks #
   #====================================================#
INFO> The following values may be preliminary because of
      free space consumption during productive operation and
      additional free space requests derived in a later stage.
      Conversions of modified tables can require additional space.
      Please use the largest free space request printed,
      which are the values at the very end of this file.
ERROR> Insufficient free space in the database as follows:
Create TABLESPACE PSAPDIMD             with 102 MB
Create TABLESPACE PSAPDIMI             with 102 MB
Create TABLESPACE PSAPODSD             with 112 MB
Create TABLESPACE PSAPODSI             with 112 MB
Create TABLESPACE PSAPFACTD            with 102 MB
Create TABLESPACE PSAPFACTI            with 102 MB
INFO> To adjust the size of your tablespaces, you may use the commands
      in file 'C:\usr\sap\put\log\ORATBSXT.LST' using the 'brspace' utility.
      Please copy the file before making changes, as it may be
      overwritten in subsequent upgrade phases.
INFO> During the upgrade, the new SAP kernel
      will be installed. All files and subdirectories
      in directory C:\usr\sap\CTD\SYS\exe\run which are not used
      in Release 700 will be removed.
      The files from "dbclient.lst" in the kernel directory are kept.
      Files and subdirectories can be protected from deletion
      if they appear in a file "protect.lst" in the same directory
      (each protected name in a separate line).
      For security reasons, directory C:\usr\sap\CTD\SYS\exe\run
      should be saved in a backup.
INFO> You already installed kernel extensions.
      Please unpack the archive(s)
      RFC.CAR
      after the upgrade has finished.
      You can find these archives on the CD "Presentation".
      Do n o t unpack the archives now, the software
      is only compatible with the new SAP kernel.
INFO> It is possible to upgrade the frontend software before
      you start SAPup!
   #===========================================================#
PREPARE module General checks finished with status failed #
   #===========================================================#
#====================================================
Execution of all selected PREPARE modules finished.
#====================================================
Now, we have the new tablespace layout and as says the upgrade general note: Note 819655 - Add. info.: Upgrade to SAP NW 2004s ABAP ORACLE we do not have to create tablespaces as saied in PREPARE; so I have adjusted tables DDART,    TAORA, IAORA: with the entry
DDIM     STD     Dimension Tables in BW
DFACT     STD     Facts Table in BW
DODS     STD     ODS Tables in BW
Then J have repeated the module: GENERAL CHECK but in the file CHECKS.LOG I noted always the same error.
Any HELPS?????
Edited by: Raffaele Pezone on Dec 1, 2009 4:25 PM
Edited by: Raffaele Pezone on Dec 1, 2009 4:34 PM

As mentioned in sap note: Note 541542 - Upgrade phase INIT_CNTRANS: Container inconsistency
we don't have standard layout:
Standard layout: TABART: TAORA-TABSPACE, IAORA-TABSPACE
SSDEF: PSAPES<rel>D,   PSAPES<rel>I
SSEXC: PSAPES<rel>D,   PSAPES<rel>I
SLDEF: PSAPEL<rel>D,   PSAPEL<rel>I
SLEXC: PSAPEL<rel>D,   PSAPEL<rel>I
APPL0: PSAPSTABD,      PSAPSTABI
USER : PSAPUSER1D,     PSAPUSER1I
<...>: PSAP<.....>D,   PSAP<.....>I
but
MCOD Layout (new layout)
SSDEF: PSAP<sid><rel>, PSAP<sid><rel>
SSEXC: PSAP<sid><rel>, PSAP<sid><rel>
SLDEF: PSAP<sid><rel>, PSAP<sid><rel>
SLEXC: PSAP<sid><rel>, PSAP<sid><rel>
APPL0: PSAP<sid>USR,   PSAP<sid>USR
USER : PSAP<sid>USR,   PSAP<sid>USR
<...>: PSAP<sid>, PSAP<sid>
but we don't use Multiple component in one Database. We have only one instance in one DB.
in fact we have following tablespaces:
PSAPSID
PSAPSID620
PSAPSID700
PSAPSIDUSR
PSAPTEMP
PSAPUNDO
SYSAUX
SYSTEM
I have just created PSAPSID700 as PREPARE says.

Need to reclaim space from dwh tables.

We have couple of large tables (> 200G) in one of the DWH schema. I need to reclaim space on the mountpoint.
I have used ALTER TABLE <> MOVE COMPRESS; command to compress these tables.
Now in dba_segments it is showing the improvement. 200g table came down to 60G. However I am not able to see any change in datafile and in mountpoint, I beleive due to the HWM.
I tried shrink for the tables, it did not help.
Could you please suggest any other approach.

refer to
http://jonathanlewis.wordpress.com/2010/01/30/free-space/
http://jonathanlewis.wordpress.com/2010/02/06/shrink-tablespace/
Anand

Can't reclaim space in tablespace after deleting records

Oracle 11gR1 RHEL5 64bit
Hi.
I am having trouble reclaiming space from a tablespace after having deleted all (thousands) of the records from a table (which resides in that tablespace). I have tried the following options to no avail:
- Alter table <table_name> shrink
- purge tablespace
- purge recyclebin
This table has several LOB columns and is using securefiles. I don't know if that has something to do with it or not. The tablespace is locally Managed and Segment space management is set to AUTO. Below is the create table command:
CREATE TABLE IIQ.DICOM_OBJECT
DICOM_OBJECT_RID NUMBER CONSTRAINT NN_DICOM_OBJECT_DICOM_OBJ_RID NOT NULL,
SUBMISSION_RID NUMBER,
SUBMISSION_ITEM_RID NUMBER,
DICOM ORDSYS.ORDDICOM,
IMAGETHUMB ORDSYS.ORDIMAGE,
ANONDICOM ORDSYS.ORDDICOM,
ACTIVE_FLAG VARCHAR2(1 CHAR) DEFAULT 'Y' CONSTRAINT NN_DICOM_OBJECT_ACTIVE_FLAG NOT NULL,
CREATED_TIMESTAMP TIMESTAMP(6) WITH LOCAL TIME ZONE DEFAULT SYSTIMESTAMP CONSTRAINT NN_DICOM_OBJECT_TIMESTAMP NOT NULL,
SOURCE_DESCRIPTION VARCHAR2(100 CHAR) CONSTRAINT NN_DICOM_OBJECT_SOURCE NOT NULL,
OP_CONFORMANCE_FLAG VARCHAR2(1 CHAR)
COLUMN IMAGETHUMB NOT SUBSTITUTABLE AT ALL LEVELS
TABLESPACE IIQDCMDAT01
PCTUSED 0
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 80K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOGGING
NOCOMPRESS
LOB ("DICOM"."EXTENSION") STORE AS SECUREFILE
( TABLESPACE IIQDCMLOB01
DISABLE STORAGE IN ROW
CHUNK 16384
RETENTION
NOCACHE
INDEX (
TABLESPACE IIQDCMLOB01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 208K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOB (SYS_NC00050$) STORE AS
( TABLESPACE IIQDCMDAT01
ENABLE STORAGE IN ROW
CHUNK 16384
PCTVERSION 10
NOCACHE
INDEX (
TABLESPACE IIQDCMDAT01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 80K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOB ("DICOM"."SOURCE"."LOCALDATA") STORE AS SECUREFILE
( TABLESPACE IIQDCMLOB01
DISABLE STORAGE IN ROW
CHUNK 16384
RETENTION
NOCACHE
INDEX (
TABLESPACE IIQDCMLOB01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 208K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOB ("ANONDICOM"."SOURCE"."LOCALDATA") STORE AS SECUREFILE
( TABLESPACE IIQDCMLOB01
DISABLE STORAGE IN ROW
CHUNK 16384
RETENTION
NOCACHE
INDEX (
TABLESPACE IIQDCMLOB01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 208K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
XMLTYPE SYS_NC00017$ STORE AS CLOB
( TABLESPACE IIQDCMLOB01
DISABLE STORAGE IN ROW
CHUNK 16384
RETENTION
CACHE READS
INDEX (
TABLESPACE IIQDCMLOB01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 208K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOB ("IMAGETHUMB"."SOURCE"."LOCALDATA") STORE AS SECUREFILE
( TABLESPACE IIQDCMLOB01
DISABLE STORAGE IN ROW
CHUNK 16384
RETENTION
NOCACHE
INDEX (
TABLESPACE IIQDCMLOB01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 208K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOB ("ANONDICOM"."EXTENSION") STORE AS SECUREFILE
( TABLESPACE IIQDCMLOB01
DISABLE STORAGE IN ROW
CHUNK 16384
RETENTION
NOCACHE
INDEX (
TABLESPACE IIQDCMLOB01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 208K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOCACHE
NOPARALLEL
MONITORING
ENABLE ROW MOVEMENT;
Thank you all.

Justin Cave wrote:
OK, so you did a SHRINK SPACE CASCADE? Not just a SHRINK SPACE?That is correct.
What makes you believe that there is more space that can be reclaimed? Well, what I don't understand is that when a table (and only that table) was assigned to a specific tablespace whose data was completely removed is showing as if the data is still there...at least when you look at the tablespace. If all the rows of a table are removed, then shouldn't the tablespace size go down? There was 95 GB of data in that tablespace and all from that one table, which was completely emptied. However, it still shows the tablespace as being 95GB full.
Can you post the size of the table segment and the LOB segments as well as the size of the actual data in the table and the LOBs?Can you tell me which views you would like to the see the data from ? dba_lobs, dba_segments, etc... I want to make sure i have the right query for you.
Here is some info...not sure if this is what you want (formatiing is off):
select owner, segment_name, segment_type, tablespace_name, bytes
from dba_segments
where owner = 'IIQ'
and tablespace_name = 'IIQDCMLOB01'
and segment_type = 'LOBSEGMENT';
OWNER SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME BYTES
IIQ SYS_LOB0000651630C00012$$ LOBSEGMENT IIQDCMLOB01 9.8416E+10
IIQ SYS_LOB0000651630C00018$$ LOBSEGMENT IIQDCMLOB01 755236864
IIQ SYS_LOB0000651630C00021$$ LOBSEGMENT IIQDCMLOB01 755236864
IIQ SYS_LOB0000651630C00023$$ LOBSEGMENT IIQDCMLOB01 262144
IIQ SYS_LOB0000651630C00044$$ LOBSEGMENT IIQDCMLOB01 262144
IIQ SYS_LOB0000651630C00053$$ LOBSEGMENT IIQDCMLOB01 262144
OWNER TABLE_NAME
COLUMN_NAME
----------------------------------- SEGMENT_NAME TABLESPACE_NAME INDEX_NAME CHUNK PCTVERSION RETENTION FREEPOOLS CACHE LOGGING ENCR COMPRE DEDUPLICATION IN_ FORMAT PAR SEC
IIQ DICOM_OBJECT
"DICOM"."SOURCE"."LOCALDATA"
SYS_LOB0000651630C00012$$ IIQDCMLOB01 SYS_IL0000651630C00012$$ 16384 10800 NO YES NO NO NO NO NOT APPLICABLE NO YES
IIQ DICOM_OBJECT
SYS_NC00018$
SYS_LOB0000651630C00018$$ IIQDCMLOB01 SYS_IL0000651630C00018$$ 16384 10800 CACHEREADS YES NO NO NO NO ENDIAN NEUTRAL NO YES
IIQ DICOM_OBJECT
"DICOM"."EXTENSION"
SYS_LOB0000651630C00021$$ IIQDCMLOB01 SYS_IL0000651630C00021$$ 16384 10800 NO YES NO NO NO NO NOT APPLICABLE NO YES
IIQ DICOM_OBJECT
"IMAGETHUMB"."SOURCE"."LOCALDATA"
SYS_LOB0000651630C00023$$ IIQDCMLOB01 SYS_IL0000651630C00023$$ 16384 10800 NO YES NO NO NO NO NOT APPLICABLE NO YES
IIQ DICOM_OBJECT
"ANONDICOM"."SOURCE"."LOCALDATA"
SYS_LOB0000651630C00044$$ IIQDCMLOB01 SYS_IL0000651630C00044$$ 16384 10800 NO YES NO NO NO NO NOT APPLICABLE NO YES
IIQ DICOM_OBJECT
"ANONDICOM"."EXTENSION"
SYS_LOB0000651630C00053$$ IIQDCMLOB01 SYS_IL0000651630C00053$$ 16384 10800 NO YES NO NO NO NO NOT APPLICABLE NO YES
Thanks.

Oracle.sql.BLOB.freeTemporary() is not freeing TEMP space in the database

Hi Folks,
We are using oracle.sql.BLOB to store some file information into the database.
Allocation of the temp space is done as below
BLOB blob=BLOB.createTemporary(conn, false, BLOB.DURATION_SESSION); // this results in the usage of TEMP space from database
And subsequent release is done as below
blob.freeTemporary(); // this should have release the space from the database.
This is on Oracle 10g, Java 1.6, ojdbc6.jar There are no exceptions. Even a simple program results in the same.
Anybody faced something similar? Any pointers would be really appreciated.
Thanks,
Deva
Edited by: user10728663 on Oct 11, 2011 5:33 AM

Thanks a lot for the information.
Memory is fine. And I am able to reproduce this within the scope of a simple example as well.
Would you have any reference to the thread which had earlier reported this as a bug. I tried a reasonable amount of search in the forum, but no success.
Thanks very much for any pointers.

How to know used space(size) of database or user?

Hi
can anyone let me know how to caluculate the used space(size) of the database ans user(schema).
Thanks in advance.

Hello,
For the used space of the database you may use the following query:
select sum(bytes)/(1024*1024) "Mo" from dba_segments;For the used space of the Schemas you may use the query below:
select owner, sum(bytes)/(1024*1024) "Mo"
from dba_segments
group by owner;Hope this help.
Best regards,
Jean-Valentin

What actually happens @Completed filling free space info for database

Hello,
i see some strange thing with my 15.7 Ase server
Earlier for a very big db of around 1TB the recovery time would be around 15Mins( i mean for the 1TB db to come online).
Now its taking only seconds to come up.
so wanted to check what actually happens in this stage.
Started filling free space info for database 'xxx'
Completed filling free space info for database 'xxx'
The difference is that we have created new server and bcpd the data into it.
Please can someone explain.
Thanks

ASE keeps counters in memory of the amount of free space available on devices and segments. When ASE is shutdown cleanly (aka "politely"), these values are flushed to disk and used to initialize the in-memory counters on reboot. If ASE is shutdown abruptly, the values have to be recalculated, a process which involves either reading every OAM page in the database or every Allocation page.

ASE - Started filling free space info for database

Hi All
I have an ASE db that is in a RECOVERY state.
This the last communication in the log: Started filling free space info for database 'BWP'
Does anyone know what this means?
There is a SAP BW running on ASE 15.7.
I am an SAP consultant working onsite at a client and the environment is down due to the DB being in this state.
Any ideas?
00:0002:00000:00014:2014/07/03 10:27:18.04 server Recovering database 'BWP'.
00:0002:00000:00014:2014/07/03 10:27:18.05 server Started estimating recovery log boundaries for database 'BWP'.
00:0002:00000:00014:2014/07/03 10:27:18.07 server Database 'BWP', checkpoint=(249429512, 203), first=(249429512, 203), last=(249429513, 46).
00:0002:00000:00014:2014/07/03 10:27:18.07 server Completed estimating recovery log boundaries for database 'BWP'.
00:0002:00000:00014:2014/07/03 10:27:18.07 server Started ANALYSIS pass for database 'BWP'.
00:0002:00000:00014:2014/07/03 10:27:18.07 server Completed ANALYSIS pass for database 'BWP'.
00:0002:00000:00014:2014/07/03 10:27:18.07 server Log contains all committed transactions until 2014/07/03 10:19:12.65 for database BWP.
00:0002:00000:00014:2014/07/03 10:27:18.07 server Started REDO pass for database 'BWP'. The total number of log records to process is 81.
00:0002:00000:00014:2014/07/03 10:27:18.14 server Completed REDO pass for database 'BWP'.
00:0002:00000:00014:2014/07/03 10:27:18.14 server Timestamp for database 'BWP' is (0x0004, 0xd609797b).
00:0002:00000:00014:2014/07/03 10:27:18.14 server Recovery of database 'BWP' will undo incomplete nested top actions.
00:0002:00000:00014:2014/07/03 10:27:18.14 server Started recovery checkpoint for database 'BWP'.
00:0002:00000:00014:2014/07/03 10:27:18.14 server Completed recovery checkpoint for database 'BWP'.
00:0002:00000:00014:2014/07/03 10:27:18.14 server Started filling free space info for database 'BWP'.
ASE VERSION:
Adaptive Server Enterprise/15.7/EBF 22779 SMP SP122 /P/x86_64/Enterprise Linux/ase157sp12x/3662/64-bit/FBO/Sat Apr 19 05:48:19 2014
Any suggestions on what to do?
J

ASE tracks the free space available on each segment in memory.
If the server is shut down politely, ASE can store the current values on disk and retrieve them at startup. However, if the server is shutdown abruptly (shutdown with nowait, crash, power failure, kill -9, etc.) the free space figures don't get written out. In that case ASE has to recalculate the free space values by reading all the allocation pages or OAM pages in the database. On a big database, that can take time.
Your main choices are to
1) wait it out
2) set the "no freespace accounting" database option and reboot
Disabling free-space accounting for data segments
While recovery will be much faster with freespace accounting turned off, there are side effects such as unexpected 1105 errors (no free space...) and thresholds not firing as expected. In general I'd advise waiting it out and trying to avoid the use of "shutdown with nowait" going forward (which may or may not be what brought the server down, but it is the main cause you can control).
-bret

Ssd reclaim space

How can I reclaim space after file deletions on NVidia MCP89 AHCI?

Boot into internet recovery and repair the disk.
Boot up holding Command Option R
Resolve startup issues and perform disk maintenance with Disk Utility and fsck

Reclaiming space in a database...

Similar Messages

Maybe you are looking for