My program creates a database schema. The queries related to tables and/or view creations work just fine but the first insert I do fails with
unable to create INITIAL extent for segment in tablespace SYSAUX
error. It is a straightforward insert in a table that has just two columns, one two strings.
The user is obviously not set to use SYSAUX tablespace and has one on its own so:
I don't understand where a SYSAUX-related failure can come from?
How to fix this?
Related
I'm using a procedure which creates a table using a heavy query (running ~1 hr). Query is something like 'select * from table', and the columns in the table can change.
Oftentimes it turns out that there is no free space in schema to create the table, so I get an exception, the time is spent in vain and I need to do the same calculations once again.
The error I get:
ORA-01536: space quota exceeded for tablespace
ORA-06512: at "UPDATE_REPORT", line 37
What I would want to do:
- Store query's results in temporary segment in a cursor;
- Try to create table using cursor. In case of exception (not enough space), drop a special space-holding table to free table space in schema;
- Try to create the table again from cursor.
I tried to solve this using dynamic SQL, but it leads to overcomplications while the problem seems to have a simple solution. And the main problem I faced is that there is no evident way to create a table using cursor.
Is there any simple solution I somehow missed out? Maybe cursor are the wrong way to work this out?
Two things I can think of:
let the database do the dirty job
a.k.a. enjoy your DBA job, simply by looking at Oracle administering itself
how? let tablespace autoextend
grant unlimited quota on that tablespace to user
Here's how (connected as a privileged user):
SQL> select file_name, tablespace_name From dba_data_files;
FILE_NAME TABLESPACE_NAME
------------------------------------------------ -----------------------------
C:\ORACLEXE\APP\ORACLE\ORADATA\XE\USERS.DBF USERS
C:\ORACLEXE\APP\ORACLE\ORADATA\XE\SYSAUX.DBF SYSAUX
C:\ORACLEXE\APP\ORACLE\ORADATA\XE\UNDOTBS1.DBF UNDOTBS1
C:\ORACLEXE\APP\ORACLE\ORADATA\XE\SYSTEM.DBF SYSTEM
SQL> alter database datafile 'C:\ORACLEXE\APP\ORACLE\ORADATA\XE\USERS.DBF'
2 autoextend on
3 maxsize unlimited;
Database altered.
SQL> alter user scott quota unlimited on users;
User altered.
SQL>
What I would want to do: - Store query's results in temporary segment in a cursor; - Try to create table using cursor. In case of exception (not enough space), drop a special space-holding table to free table space in schema; - Try to create the table again from cursor.
Don't go through the trouble. Just tell Oracle not to die because of space issues.
You can make your session "resumable" so that, rather than giving you an error when you run out of space, Oracle will suspend your session until the problem is corrected (and then continue on automatically).
Assuming you have all the permissions you need (notably, GRANT RESUMABLE TO yourschema), you enable it like this:
alter session enable resumable timeout 1800 name 'your process name, can be anything';
The 1800 number is in seconds, giving your DBA's 30 minutes to fix the problem before your session times out. The "my process" will show up in V$RESUMABLE for use in queries and automated alerts.
Your DBAs can monitor V$RESUMABLE and/or you can create a schema-level database trigger on the AFTER SUSPEND event to fire off an e-mail to them when they need to jump in.
I agree with #OldProgrammer - this is a design problem. Dropping and re-creating tables is an anti-pattern.
It's not clear what exact problem you're trying to solve, but a more sensible approach might be:
Create the table once. Use INITIAL EXTENT parameter to ensure that the table has all the space it needs (you may have to run some queries to establish what that figure should be).
Check with your DBA that the tablespace is set to AUTOEXTEND, in case there are rogue result sets which exceed your calculations. Maybe negotiate more tablespace quota for the schema owner.
Populate the table once.
Before subsequent runs, TRUNCATE the table using the REUSE STORAGE clause to hold on to the assigned space.
While creating tables or indexes, I always get the recommendation to add tablespace clause in the queries. Is there any major impact later on our table if we don't use the tablespace clause while creating them ?
This is what I am doing for a very long time.
CREATE TABLE XT_PMB_NOTIFY_UNSUB(
TXNID NUMBER(15),
APP_SEQNO NUMBER(15),
PRIMARY_KEYVAL VARCHAR2(4000) NOT NULL,
OP_CODE VARCHAR2(15),
TXN_STATUS VARCHAR2(1),
CREATE_DT DATE,
PRIMARY KEY (TXNID) );
Recommendation from DBA.
CREATE TABLE XT_PMB_NOTIFY_UNSUB(
TXNID NUMBER(15),
APP_SEQNO NUMBER(15),
PRIMARY_KEYVAL VARCHAR2(4000) NOT NULL,
OP_CODE VARCHAR2(15),
TXN_STATUS VARCHAR2(1),
CREATE_DT DATE,
PRIMARY KEY (TXNID) )
TABLESPACE DATA_ENC_TS;
The answer is it depends on how your company has defined its tablespace rules.
Oracle users (or schemas) can have one "default tablespace" which you can see by querying the database:
select username, default_tablespace from dba_users;
or if you do not have permission for that and you want to know what it is for the current user only:
select username, default_tablespace from user_users;
Or perhaps this one to see all users that are visible to your current connected user:
select username, default_tablespace from user_users;
According to Oracle documentation (https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8003.htm) this is what it means:
Specify the default tablespace for objects that the user creates. If
you omit this clause, then the user's objects are stored in the
database default tablespace. If no default tablespace has been
specified for the database, then the user's objects are stored in the
SYSTEM tablespace.
So for your intents and purposes, when you create a table without explicitly using a tablespace at the end it will go to the user's default tablespace in general. If your DBAs tend to not define a default tablespace then it starts to have more serious impacts, because the table will be stored in a global default tablespace or (heaven forbid) it will go to SYSTEM tablespace. That last option would be extremely detrimental to the database health.
Some companies have the habit of assigning different tablespaces for tables and for indexes for instance. In that case, the users can only have one default tablespace, and if you omit the tablespace clause in the create index (or create table) statement, objects will go to the incorrect tablespace.
Now to the consequences of having a table or index in an incorrect tablespace. A tablespace is a collection of one or more physical operating system files (Oracle refers to them as data files). Whenever you create a table or index in a tablespace oracle allocates space in that datafile, which Oracle calls segments. Segments are logical units inside a data file. Keep in mind Oracle further breaks down segments into smaller logical units called extents and blocks, but that is a bit beyond the topic here. If you are interested there is more to read here: https://docs.oracle.com/cd/B19306_01/server.102/b14220/logical.htm
Let's go back to segments. Segments exist inside datafiles that belong to tablespaces. When you put your object in a tablespace and you want to move it out to a different tablespace, Oracle needs to physically write to files on the OS. And that can be simple if the table is empty, or can be a fair amount of work if it concerns a massive table spanning multiple datafiles or containing gigabytes or terabytes of data. It may mean an application outage is required to fix it.
Oracle provides certain methods to avoid application outages in those scenarios, like for example Online Redefinition (package DBMS_REDEFINITION). But I would hope we can agree that their use can be better leveraged for application migrations and things of the sort.
Using default tablespace settings is fine in many cases, by all means, but if you will allow me perhaps, the rule of thumb for many things Oracle is if you can write code to do something explicitly instead of relying on default values, do yourself and your DBA the favor. In general, the flexibility of relying on it is trumped by even a couple times of facing yourself with a surprise and then being responsible for cleaning it up later.
If you don't specify a tablespace, Oracle will use the default tablespaces assigned to the schema. You can find your default tablespace with the query below. Unless you have a very small development database w/o many schemas, that may be OK, but otherwise it is good practice to explicitly define them.
select *
from database_properties
where property_name like 'DEFAULT%TABLESPACE';
PROPERTY_NAME PROPERTY_VALUE DESCRIPTION
------------------------------ -------------------- ----------------------------------------
DEFAULT_TEMP_TABLESPACE TEMP Name of default temporary tablespace
DEFAULT_PERMANENT_TABLESPACE USERS Name of default permanent tablespace
In case of Locally managed SYSTEM tablespace, when objects are created in a user tablespace (which is also locally managed) initial extents are getting allocated only after data insertion.
Whereas in the same scenario where SYSTEM tablespace is dictionary managed, initial extent gets allocated whenever table is created.
create tablespace lmt datafile 'df.f' size 5M extent management local;
conn scott/tiger
create table sample (id nuber) tablespace lmt;
select * from user_tables where table_name = 'SAMPLE';
initial extent is null when SYSTEM tablespace is Locally managed
initial extent has value when SYSTEM tablespace is dictionary managed
After data insertion, initial extent is allocated in case (1)
Is this the expected behavior? because as per Oracle docs, 'Oracle allocates space for initial extent when you create the schema object'
I think you're quoting (or rather, slightly paraphrasing) this part of the documentation:
INITIAL
Specify the size of the first extent of the object. Oracle allocates space for this extent when you create the schema object. ...
That isn't the whole story though. Tables can be created with deferred segment creation:
deferred_segment_creation
Use this clause to determine when the database should create the segment(s) for this table:
SEGMENT CREATION DEFERRED: This clause defers creation of the table segment — as well as segments for any LOB columns of the table, any indexes created implicitly as part of table creation, and any indexes subsequently explicitly created on the table — until the first row of data is inserted into the table. ...
SEGMENT CREATION IMMEDIATE: The table segment is created as part of this CREATE TABLE statement.
It looks like what you are seeing is nothing to do with the SYSTEM tablespace being locally managed, as you suspected, and that is just a coincidence. The difference is the default for segment creation, which is controlled by an initialisation parameter, deferred_segment_creation. From what you've shown that is set to TRUE in the database that has the locally-managed SYSTEM tablespace, and FALSE in the one that has that dictionary-managed.
You can get consistent behaviour by overriding the default, either to defer creation:
create table sample (id number) segment creation deferred tablespace lmt;
Table SAMPLE created.
set null "(null)"
select initial_extent from user_tables where table_name = 'SAMPLE';
INITIAL_EXTENT
--------------
(null)
or to create immediately:
create table sample (id number) segment creation immediate tablespace lmt;
Table SAMPLE created.
select initial_extent from user_tables where table_name = 'SAMPLE';
INITIAL_EXTENT
--------------
65536
Or you could change the initialisation parameters to be the same, of course, but that's more work and might affect other code that assumes the current behaviour.
In Oracle schema used size can be greater than tablespace used size ? If yes how its possible as schema is associated with tablespace ?
A schema is not "associated" with a tablespace.
A user (=schema) can have a default tablespace, but that does not necessarily mean that all tables that user owns are stored in that default tablespace. If the user has the privileges, tables can be created in other tablespaces as well.
In addition to what #a_horse_with_no_name mentioned, you need to undrstand few basics of orale as well.
Oracle Tablespace -
This is a logical structure, meaning that a tablespace is not a
physical object
A tablespace is made of 1 or more physical structures called
datafiles. A datafile is a physical file on disk, just like any other file which sits on a hard disk but in an Oracle format. The datafile is created as part of a tablespace, and only one tablespace
Each tablespace can have different characteristics, such as extent
size and how the extents are managed
They are used to group segments into logical
groups. For example, you may have accounting data in one tablespace
and reporting data in another.
The Oracle Schema or User
Oracle Schema and user are synonymous and the terms are usually used
interchangeably
There can be thousands of users within one database
The schema owns segments and objects (tables, indexes,views,
constraints, etc) and each segment/object can belong to only one
schema
How can we shrink temp tablespace in oracle? And why it is increasing so much like upto 25 GB since there is only one schema in the database for the application and data table space size is 2 GB and index table space size is 1 GB used.
Oh My Goodness! Look at the size of my temporary table space!
Or... how to shrink temporary tablespaces in Oracle.
Yes I ran a query to see how big my temporary tablespace is:
SQL> SELECT tablespace_name, file_name, bytes
2 FROM dba_temp_files WHERE tablespace_name like 'TEMP%';
TABLESPACE_NAME FILE_NAME BYTES
----------------- -------------------------------- --------------
TEMP /the/full/path/to/temp01.dbf 13,917,200,000
The first question you have to ask is why the temporary tablespace is so large.
You may know the answer to this off the top of your head. It may be due to a
large query that you just run with a sort that was a mistake (I have done that
more than once.) It may be due to some other exceptional circumstance. If that
is the case then all you need to do to clean up is to shrink the temporary
tablespace and move on in life.
But what if you don't know? Before you decide to shrink you may need to do some
investigation into the causes of the large tablespace. If this happens on a
regular basis then it is possible that your database just needs that much space.
The dynamic performance view
V$TEMPSEG_USAGE
can be very useful in determining the cause.
Maybe you just don't care about the cause and you just need to shrink it.
This is your third day on the job. The data in the database is only 200MiB
if data and the temporary tablespace is 13GiB - Just shrink it and move on.
If it grows again then we will look into the cause. In the mean time I am
out of space on that disk volume and I just need the space back.
Let's take a look at shrinking it. It will depend a little on what version
of Oracle you are running and how the temporary tablespace was set up.
Oracle will do it's best to keep you from making any horrendous mistakes
so we will just try the commands and if they don't work we will shrink
in a new way.
First let's try to shrink the datafile. If we can do that then we get back
the space and we can worry about why it grew tomorrow.
SQL>
SQL> alter database tempfile '/the/full/path/to/temp01.dbf' resize 256M;
alter database tempfile '/the/full/path/to/temp01.dbf' resize 256M
*
ERROR at line 1:
ORA-03297: file contains used data beyond requested RESIZE value
Depending on the error message you may want to try this with different sizes
that are smaller than the current site of the file. I have had limited
success with this. Oracle will only shrink the file if the temporary tablespace
is at the head of the file and if it is smaller than the size you
specify. Some old Oracle documentation (they corrected this) said that
you could issue the command and the error message would tell you what
size you could shrink to. By the time I started working as a DBA this was
not true. You just had to guess and re-run the command a bunch of times
and see if it worked.
Alright. That didn't work. How about this.
SQL> alter tablespace YOUR_TEMP_TABLESPACE_NAME shrink space keep 256M;
If you are in 11g (Maybee in 10g too) this is it! If it works you may want
to go back to the previous command and give it some more tries.
But what if that fails. If the temporary tablespace is the default temporary
that was set up when the database was installed then you may need to do a
lot more work. At this point I usually re-evaluate if I really need that
space back. After all disk space only costs $X.XX a GiB. Usually I don't want
to make changes like this during production hours. That means working at 2AM
AGAIN! (Not that I really object
to working at 2AM - it is just that... Well I like to sleep too. And my wife
likes to have me at home at 2AM... not roaming the downtown streets at 4AM trying
to remember where I parked my car 3 hours earlier. I have heard of that "telecommuting"
thing. I just worry that I will get half way through and then my internet connectivity
will fail - then I have to rush downtown to fix it all before folks show up in the
morning to use the database.)
Ok... Back to the serious stuff...
If the temporary tablespace you want to shrink is your default
temporary tablespace, you will have to first create a new temporary
tablespace, set it as the default temporary tablespace then drop
your old default temporary tablespace and recreate it. Afterwords
drop the second temporary table created.
SQL> CREATE TEMPORARY TABLESPACE temp2
2 TEMPFILE '/the/full/path/to/temp2_01.dbf' SIZE 5M REUSE
3 AUTOEXTEND ON NEXT 1M MAXSIZE unlimited
4 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
Tablespace created.
SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2;
Database altered.
SQL> DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES;
Tablespace dropped.
SQL> CREATE TEMPORARY TABLESPACE temp
2 TEMPFILE '/the/full/path/to/temp01.dbf' SIZE 256M REUSE
3 AUTOEXTEND ON NEXT 128M MAXSIZE unlimited
4 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
Tablespace created.
SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;
Database altered.
SQL> DROP TABLESPACE temp2 INCLUDING CONTENTS AND DATAFILES;
Tablespace dropped.
Hopefully one of these things will help!
The options for managing tablespaces have got a lot better over the versions starting with 8i. This is especially true if you are using the appropriate types of file for a temporary tablespace (i.e. locally managed tempfiles).
So, it could be as simple as this command, which will shrink your tablespace to 128 meg...
alter tablespace <your_temp_ts> shrink space keep 128M;
The Oracle online documentation is pretty good. Find out more.
edit
It would appear the OP has an earlier version of the database. With earlier versions we have to resize individual datafiles. So, first of all, find the file names. One or other of these queries should do it...
select file_name from dba_data_files where tablespace_name = '<your_temp_ts>'
/
select file_name from dba_temp_files where tablespace_name = '<your_temp_ts>'
/
Then use that path in this command:
alter database datafile '/full/file/path/temp01.dbf' resize 128m
/
You should have written what version of Oracle you use. You most likely use something else than Oracle 11g, that's why you can't shrink a temp tablespace.
Alternatives:
1) alter database tempfile '[your_file]' resize 128M; which will probably fail
2) Drop and recreate the tablespace. If the temporary tablespace you want to shrink is your default temporary tablespace, you may have to first create a new temporary tablespace, set it as the default temporary tablespace then drop your old default temporary tablespace and recreate it. Afterwards drop the second temporary table created.
3) For Oracle 9i and higher you could just drop the tempfile(s) and add a new one(s)
Everything is described here in great detail.
See this link: http://databaseguide.blogspot.com/2008/06/resizing-temporary-tablespace.html
It was already linked, but maybe you missed it, so here it is again.
It will be increasing because you have a need for temporary storage space, possibly due to a cartesian product or a large sort operation.
The dynamic performance view V$TEMPSEG_USAGE will help diagnose the cause.
Temporary tablespaces are used for database sorting and joining operations and for storing global temporary tables. It may grow in size over a period of time and thus either we need to recreate temporary tablespace or shrink it to release the unused space.
Steps to shrink TEMP Tablespace
alter database datafile 'C:\ORA_SERVER\ORADATA\AXAPTA\AX_DATA.ORA' resize 40M;
If it doesn't help:
Create new tablespace
Switch to new temporary tablespace
Wait until old tablespace will not be used
Delete old tablespace
I don't bother with dropping the alternate temp in case i need to reclaim storage again in the future...
from temp group set default to stand-alone temp
wait awhile, then resize members of temp group
set default back to temp group
wait awhile, resize stand alone temp. there's no rush to do the last step