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.
Related
I am learning about tablespaces, but I am not sure what a segment of a tablespace constitutes. Is it safe to say that the following query displays all schema objects that can be moved to different tablespaces:
select distinct segment_type
from dba_segments;
Result:
SEGMENT_TYPE
------------------
LOBINDEX
INDEX PARTITION
TABLE SUBPARTITION
ROLLBACK
TABLE PARTITION
NESTED TABLE
LOB PARTITION
LOBSEGMENT
INDEX
TABLE
TYPE2 UNDO
CLUSTER
A segment represents the storage associated with an object such as a table or index. Segments reside in tablespaces.
You probably won't be moving rollback or undo segments, as those will be in their own dedicated tablespace and are system-managed in recent versions of Oracle.
I don't think there is a convenient way to move a cluster to a new tablespace, but then aside from the ones used internally for the data dictionary they are rarely used, so probably you won't have to deal with those either.
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
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?
Currently by default create table and index DDLs will place tables in MYDB_DATA_TABLE_SPACE, I would like to specify a different default table space for indexes from table data so that I do not have to always explicitly mention that in my create index DDL. Is this possible?
Current:
Table -> MYDB_DATA_TABLE_SPACE
Required:
Table -> MYDB_DATA_TABLE_SPACE
Index -> MYDB_INDX_TABLE_SPACE
You can't specify a different default tablespace for indexes and for tables. Each user only gets one default tablespace.
Hopefully, you're not trying to maintain separate tablespaces for performance reasons. There is a relatively common myth that you can improve performance by storing data and indexes in separate tablespaces. I'm personally not a big fan of putting indexes and data in different tablespaces-- there are no performance differences, it is terribly unlikely that you could run the application without the index tablespace so there aren't any recoverability benefits. I understand that it can appeal to some folks sense of organization so I don't object categorically.
Sorry, there is no way to do that.
A default tablespace may be set per user, but it applies to all segment creation: tables, indexes, materialized views, etc.
Hope that helps.
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.