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
Related
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.
In Oracle, is it possible to store in one tablespace the data for two tables that share the same name but are defined for different users (schemas)?
Or maybe I need to create separate tablespace per user if there might be a name clash?
I cannot easily check it for myself, as I dont' have any instance with proper privilliges available currently.
If you mean you have 2 users (schemas) so yes you can create 2 tables with same name with different users for example create table user1.tab1 ... and create table user2.tab1 ...
I need to create separate tablespace per user if there might be a name
clash
let me do some explanation ..in oracle you already have several users , for example system users that as it obvious have high privileges then you have/create other users that have specific privilege , every users has his own objects, his own tables , procedure... and this users and its objects normally and can resides in one datafiles which the datafile resides in the tablespace.
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
I have an Oracle table that is in it's own tablespace. It has a spatial index in another tablespace and a normal index in another. If I want to drop them all. Does it matter what order I proceed in?
Drop the table. The indexes will be dropped along with the table.
Indexes are optional structures associated with tables and clusters. If you drop the table, the associated indexes are also dropped.
To answer your confusion about different tablespaces, there is a reason to create in different tablespace or within same tablespace as that of the table. Keeping them in same tablespace makes it easy for database maintenance, however, keeping in different tablespaces is better in terms of performance.
From documentation -
Indexes can be created in any tablespace. An index can be created in
the same or different tablespace as the table it indexes. If you use
the same tablespace for a table and its index, it can be more
convenient to perform database maintenance (such as tablespace or file
backup) or to ensure application availability. All the related data is
always online together.
Using different tablespaces (on different disks) for a table and its
index produces better performance than storing the table and index in
the same tablespace. Disk contention is reduced. But, if you use
different tablespaces for a table and its index and one tablespace is
offline (containing either data or index), then the statements
referencing that table are not guaranteed to work.
My question regards the situation were tablespace used for primary key index differs from tablespace used for the table itself. Will Oracle use this index or it becomes unusable?
Because when i tried to import the schema to Oracle that contains that table. Oracle complained with warning saying that index for this primary key is unusable. I've fixed the schema by change tablespace for primary key index, exported it again and it imported into database without warnings.
Does this means that primary key index tablespace must be always the same as the tablespace of the table itself? Or is it true for any kind of index (column index for example)?
Does this rule apply also for DB2?
Storing indexes and data in different tablespaces is perfectly acceptable. What happens when you do a:
alter index index_name rebuild;
Is the index still unusable after that? If not, check your import parameters on the table. For example, SQL*Loader can invalidate indexes with direct path loads (this is just a guess, you don't mention how you loaded the data).
If the index is still unusable, check for data anomalies, especially duplicate keys. Hope you fix it!
What Martin said is fine. However, there is no real need to separate the tablespaces. What you can do, to avoid tablespace errors on import (assuming you're using export/import and not datapump) is to create the user with a default tablespace that exists. Then import just the database and then add the indexes and constraints.