There is a schema called Docker, in which there are tables named TABLE2, TABLE3.
Example
SELECT * FROM all_all_tables WHERE TABLE_name= 'TABLE3';
Also, the Docker schema belongs to the DEFAULT TABLESPACE SYSTEM tablespace.
select
username
, default_tablespace from dba_users WHERE USERNAME = 'DOCKER';
The following syntax is used to change the default tablespace of the schema. (TS3 tablespace already exists)
ALTER USER docker DEFAULT tablespace TS3;
Then, when I searched again, I found that the DEFAULT TABLESPACE was changed.
select
username
, default_tablespace from dba_users WHERE USERNAME = 'DOCKER';
And, of course, I thought that the tablespace in which TABLE2 and TABLE3 were designated would also have been changed to TS3, and the following statement was executed.
However, the tablespace of the table was SYSTEM, not TS3. I am curious about why it hasn't changed, and I want to know how.
SELECT * FROM all_all_tables WHERE TABLE_name= 'TABLE3';
The default tablespace is just that-- a default for when you create a segment (normally a table or an index but a segment could be a partition of a table, a materialized view, or anything else that requires space) and don't specify the tablespace. Once you create a segment and it is assigned to a particular tablespace, it will remain in that tablespace unless you move it.
Assuming you are on 12.2 or later so that online moves are an option (in other versions you'd need to remove the online keyword)
alter table table3
move online tablespace ts3;
You'd need to do that for each table. If there are also indexes in the system tablespace, you'd want to move those as well
alter index index_name
rebuild online tablespace ts3;
Depending on the number of tables and indexes involved, you may want to write a bit of dynamic SQL to generate the various alter table and alter index statements for you.
Related
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
I have the following PL/SQL code:
DROP TABLE TAB_PARAM;
BEGIN
EXECUTE IMMEDIATE 'CREATE TABLE TAB_PARAM
(
TABLE_OWNER VARCHAR2(30) NOT NULL,
TABLE_NAME VARCHAR2(30) NOT NULL,
COLUMN_NAME VARCHAR2(30) NOT NULL,
PATTERN VARCHAR2(1024),
TYPE_METHODE VARCHAR2(30) NOT NULL,
SEPARATEUR VARCHAR2(20),
ID VARCHAR2(30),
CONSTRAINT PK_TAB_PARAM PRIMARY KEY (TABLE_OWNER,TABLE_NAME,COLUMN_NAME) USING INDEX TABLESPACE IND_PARC_256M NOLOGGING
)
TABLESPACE TAB_PARC_256M NOLOGGING NOCACHE NOMONITORING NOPARALLEL';
commit;
END;
/
I don't understand the part :
CONSTRAINT PK_TAB_PARAM PRIMARY KEY (TABLE_OWNER,TABLE_NAME,COLUMN_NAME) USING INDEX TABLESPACE IND_PARC_256M NOLOGGING
Nor the part:
TABLESPACE TAB_PARC_256M NOLOGGING NOCACHE NOMONITORING NOPARALLEL';
I know that it is setting the ID as primary key of TAB_PARAM but then I do not get the index part.
Can anyone help me understand this code please?
Sometimes you can create a table in a disposable way , for example you need to read data via sqlloader from file and insert in table , after that you will select all records from table . This operation doesnt need indexes and doesnt need primary key . Anyway it is always good to create primary key when you create a table and Oracle will create index for you . You can create more indexes whenever you want since the table was created . Now suppose you wanna update the table using where condition on a field who is not a primary key , it could be a better decision create an index on that field . In addition when you create indexes or table , you can associate tablespaces (created before) and could be good practice separate tablespaces for tables and indexes . All those operations are DDL Statements . In Oracle you can check datafiles , tables and indexes with those queries select * from dba_data_files; select * from dba_tables; select * from dba_indexes;
For primary key oracle implicitly creates unique index in table's tablespace.
This part USING INDEX TABLESPACE allow us to indicate tablespace for this implicitly index.
NOLOGGING - data is modified with minimal logging (to mark new extents invalid and to record dictionary changes).
NOCACHE - Oracle doesn't store blocks in the buffer cache.
NOPARALLEL - Parallel execution is not allowed on this table.(Default value)
NOMONITORING - Disable statistics collection. Now is deprecated. There is other mechanism to collect statistic
Edit. from oracle doc
Oracle Database uses an existing index if it contains a unique set of values before enforcing the primary key constraint. The existing
index can be defined as unique or nonunique. When a DML operation is
performed, the primary key constraint is enforced using this existing
index.
If there already index hitting the pk columns , oracle will used it, else then Oracle Database generates a unique index.
so you can create a primary key in oracle without an index if there was already index for that columns , specifying an index is for performance issue. The purpose of an index in a table is to 'read' the data faster.
From the oracle document
An index is a schema object that contains an entry for each value that
appears in the indexed column(s) of the table or cluster and provides
direct, fast access to rows.
As for the TABLESPACE, its where the database object exists, so when you create a table you specify in which tablespace you want it to exists. Read more here oracle document
As for NOLOGGING NOCACHE NOMONITORING, so the table not to be logged in redo logs or cached, also related to performance issue.
I have lots of table with lots of records in oracle 11g. (more than 2 billions) After applying some queries and creating some indexes I am so close to insufficient disk space. Right now for executing each query ORA-01652 error for USERS tablespace appears. I cannot add more datafile to USERS tablespace anymore because of insufficient disk space. I am sure that there are lots of unused space available on this tablespace that is not usable somehow. (I deleted some tables and indexes nothing happened) My question is how can I release this space? Thank you very much.
I don't know if you can to it for an entire tablespace but for a single table the command is:
ALTER TABLE MY_TABLE ENABLE ROW MOVEMENT; -- By defaut ROW MOVEMENT is disabled when you create a table.
ALTER TABLE MY_TABLE SHRINK SPACE CASCADE;
ALTER TABLE MY_TABLE DEALLOCATE UNUSED;
Maybe you have to loop over ALL_TABLES in your schema.
Then you can gain disc space by rebuilding your indexes.
ALTER INDEX THE_INDEX REBUILD;
I run oracle 11g and need to move table (tbl1) from one tablespace (tblspc1) to another (tblspc2). What is the easiest way to do that?
Try this:-
ALTER TABLE <TABLE NAME to be moved> MOVE TABLESPACE <destination TABLESPACE NAME>
Very nice suggestion from IVAN in comments so thought to add in my answer
Note: this will invalidate all table's indexes. So this command is usually followed by
alter index <owner>."<index_name>" rebuild;
Use sql from sql:
spool output of this to a file:
select 'alter index '||owner||'.'||index_name||' rebuild tablespace TO_TABLESPACE_NAME;' from all_indexes where owner='OWNERNAME';
spoolfile will have something like this:
alter index OWNER.PK_INDEX rebuild tablespace CORRECT_TS_NAME;
Moving tables:
First run:
SELECT 'ALTER TABLE <schema_name>.' || OBJECT_NAME ||' MOVE TABLESPACE '||' <tablespace_name>; '
FROM ALL_OBJECTS
WHERE OWNER = '<schema_name>'
AND OBJECT_TYPE = 'TABLE' <> '<TABLESPACE_NAME>';
-- Or suggested in the comments (did not test it myself)
SELECT 'ALTER TABLE <SCHEMA>.' || TABLE_NAME ||' MOVE TABLESPACE '||' TABLESPACE_NAME>; '
FROM dba_tables
WHERE OWNER = '<SCHEMA>'
AND TABLESPACE_NAME <> '<TABLESPACE_NAME>
Where <schema_name> is the name of the user.
And <tablespace_name> is the destination tablespace.
As a result you get lines like:
ALTER TABLE SCOT.PARTS MOVE TABLESPACE USERS;
Paste the results in a script or in a oracle sql developer like application and run it.
Moving indexes:
First run:
SELECT 'ALTER INDEX <schema_name>.'||INDEX_NAME||' REBUILD TABLESPACE <tablespace_name>;'
FROM ALL_INDEXES
WHERE OWNER = '<schema_name>'
AND TABLESPACE_NAME NOT LIKE '<tablespace_name>';
The last line in this code could save you a lot of time because it filters out the indexes which are already in the correct tablespace.
As a result you should get something like:
ALTER INDEX SCOT.PARTS_NO_PK REBUILD TABLESPACE USERS;
Paste the results in a script or in a oracle sql developer like application and run it.
Last but not least, moving LOBs:
First run:
SELECT 'ALTER TABLE <schema_name>.'||LOWER(TABLE_NAME)||' MOVE LOB('||LOWER(COLUMN_NAME)||') STORE AS (TABLESPACE <table_space>);'
FROM DBA_TAB_COLS
WHERE OWNER = '<schema_name>' AND DATA_TYPE like '%LOB%';
This moves the LOB objects to the other tablespace.
As a result you should get something like:
ALTER TABLE SCOT.bin$6t926o3phqjgqkjabaetqg==$0 MOVE LOB(calendar) STORE AS (TABLESPACE USERS);
Paste the results in a script or in a oracle sql developer like application and run it.
O and there is one more thing:
For some reason I wasn't able to move 'DOMAIN' type indexes. As a work around I dropped the index. changed the default tablespace of the user into de desired tablespace. and then recreate the index again.
There is propably a better way but it worked for me.
Try this to move your table (tbl1) to tablespace (tblspc2).
alter table tb11 move tablespace tblspc2;
I tried many scripts but they didn't work for all objects. You can't move clustered objects from one tablespace to another. For that you will have to use expdp, so I will suggest expdp is the best option to move all objects to a different tablespace.
Below is the command:
nohup expdp \"/ as sysdba\" DIRECTORY=test_dir DUMPFILE=users.dmp LOGFILE=users.log TABLESPACES=USERS &
You can check this link for details.
I'd like to ask a question.
What happen If I create an index without specifying the tablespace in the process of creation.
For example :
CREATE INDEX indx_cd on distributors(dist_cd)
In what tablespace does the index created? And will the index still works as it should even if I put it that way?
The index will be created in the default tablespace of the schema.
As system user you can determine what tablespace that is:
select username,default_tablespace from dba_users