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
Related
On Oracle 12c, is the content of each datafile belonging to a single tablespace the same?
If yes, is it because of performance or backup purpose thus recommanding us to store each datafile on different drives?
If no then why would we create multiple datafiles for a single tablespace when we can autoextend each datafile?
No.
The idea of multiple datafiles supporting a single tablespaces is to be able to use striping. This ofcourse only makes sense if your server has multiple physical storage devices that preferably also have their own io interface.
À table will be in the tablespaces and can allocate space in all available datafiles. So the table data can be in all datafiles.
If your io system does not consist of multiple physical devices you might as well use a bigfile tablespace that just has one big datafile. In older releases this was a restore nightmare because the backup and restore was performed file by file.
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 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.
In oracle what's the differences between a database and a table space?
A little terminology:
Oracle defines a database as the set of files that you find on your Oracle system. This means all data in your Oracle system is in these database files, commonly known as "data files". There are other files in the database such as parameter files and redo logs.
On the other hand, an instance consists of the processes and memory areas that Oracle database uses. Together, a database and an instance make up a database system. (For more information, see the Oracle Concept guide)
Logically, you will want to define different spaces within that database. This is done via tablespaces (see Oracle Concept guide). A tablespace usually consists of one or more data files. When you define a table with CREATE TABLE, you can specify in which tablespace the table should be created. This allows you to seperate different applications on the same database system, for example.
The Oracle Concepts guide is an excellent source of information for questions like these. See this picture on how data files and tablespaces are composed.
Let's consider an example of an Ocean consist of lots of water. Now you want that water. For this what you do is collect water in barrel for better usage and better storage purpose. Same here Ocean is database having lots of Data files here data file means water and for better usage and handling you put that into barrel you can relate barrel as Tablespace
An Oracle database consists of one or more logical storage units
called tablespaces, which collectively store all of the database's
data.
Databases, tablespaces, and datafiles are closely related, but they have important differences:
Each tablespace in an Oracle database consists of one or more files
called datafiles, which are physical structures that conform to the
operating system in which Oracle is running.
A database's data is collectively stored in the datafiles that
constitute each tablespace of the database. For example, the simplest
Oracle database would have one tablespace and one datafile. Another
database can have three tablespaces, each consisting of two datafiles
(for a total of six datafiles).
reference link
DATABASES's data are stored in logical storage units called TABLESPACES. A database may contain "one or more" tablespaces. A tablespace may contain one or more datafiles.
A database's data is collectively stored in the datafiles that constitute each tablespace of the database.
Example: the simplest database may have one tablespace and one datafile. On the other hande another database can have 5 tablespaces which may contain two datafiles each (On a total of 10 files)
This question is quite dated. IBM Db2 also has Table spaces. I think there is some commonality between Db2 table spaces and Oracle database table spaces. In that respect this link offers more insight into why table spaces, as storage structures, are needed and how are they distinct from databases. Two benefits are easy recoverability of the database and better storage management.
Given that
there is a single tablespace pointing to one file, and there are many schemas pointing to that tablespace and there are many simultaneous jobs doing heavy DDL operations (dropping database, dropping indexes, creating a large database from scratch with data import) using these schemas,
is it possible the tablespace somehow locked so that there would be timeouts for some jobs using these schemas?