What Does This Oracle SQL Statement Do? - sql

I am migrating a MSSQL script to Oracle SQL and I can't figure out what one line in the script is doing.
I am very new to SQL.
CREATE TABLE HA_BACKUP_PROCESSES
(
ID numeric (10, 0) NOT NULL ,
PROCESS_ID numeric (10, 0) NOT NULL ,
BACKUP_PROCESS_ID numeric (10, 0) NOT NULL ,
CONSTRAINT HA_BCK_PROC_PK PRIMARY KEY (ID)
USING INDEX TABLESPACE userdata001
)
In the above code, what is the 'USING INDEX TABLESPACE userdata001' statement doing?

This clause allows selection of the tablespace in which the index associated with a UNIQUE or PRIMARY KEY constraint will be created. If not specified, default_tablespace is used, or the database's default tablespace if default_tablespace is an empty string

Tablespaces are nothing more than logical containers for datafiles and indexes.
When setting up an Oracle instance, you must define your tablespaces before you can create datafiles. Then, when you create a table or index you must specify the tablespace you want to create the datafile in, or accept the default tablespace.

It instructs the database to store index information in the tablespace named "userdata001".
A helpful explanation can be found here:
A tablespace is a logical storage unit within an Oracle database. It is logical because a tablespace is not visible in the file system of the machine on which the database resides. A tablespace, in turn, consists of at least one datafile which, in turn, are physically located in the file system of the server. Btw, a datafile belongs to exactly one tablespace.
Each table, index and so on that is stored in an Oracle database belongs to a tablespace. The tablespace builds the bridge between the Oracle database and the filesystem in which the table's or index' data is stored.

Related

using index tablespace?

I came across two code snippets :
one...
ALTER TABLE table_name
DROP CONSTRAINT constraint_name;
DROP INDEX index_name;
alter TABLE table_name ADD CONSTRAINT constraint_name PRIMARY KEY (column, column)
USING INDEX TABLESPACE tablespace_name;
Two ...
CREATE INDEX index_name ON table_name (column_name)
TABLESPACE tablespace_name;
Now I can understand the statements that are not in bold but the statements in bold are quite difficult to understand. Why are we using tablespaces, especially in this context? What is the meaning of these two statements? Can someone give me a detailed answer with examples?
Thank you!
A tablespace is a logical storage unit. Actual OS storage is defined in datafiles, and datafiles are linked to a tablespace. This means that we can deploy database objects on different servers, different OS even, without needing to know the underlying directory structure.
As for index tablespaces, indexes are physical objects and need to be stored somewhere. These days it is not as common to distinguish between Index tablespaces and table tablespaces, because modern servers are raided, striped, etc so nobody need worry about disk heads.
In fact, Oracle's built-in tablespace management is so good that we can largely forget about tablespace planning altogether. There is still a case for having separate tablespaces for e.g. read-only data, transportable tablespaces, partitioning, etc.

Create a temporary table in temporary tablespace db2

Is there a way to create a system The table was not created because the table space "TEMPTB" following the clause "IN" is a "SYSTEM TEMPORARY" table space. SQLSTATE=42838
This is the error I keep getting when I create a temp table in a temp tablespace...does db2 not support it? because oracle does.
Thanks
System Temporary tablespaces are used only for system-created temporary objects – for joins, sorts that are too large for the sort heap, table queues that overflow, etc.
You need to create a USER TEMPORARY tablespace. You can read more about the various types of tablespaces. And use the CREATE TABLESPACE command to create one.

Removing tablespace references from database scripts

I am relatively new to SQL and only dabble with it when it is required. I have done some research on this but have limited success. I need to remove the tablespace references from the code. The settings already exist in the database for a default tablespace. By the way it is an Oracle database.
If I have these lines of code:
EXECUTE IMMEDIATE 'CREATE TABLE RAND_CATEGORY(
-------- insert random vars ---------------
CONSTRAINT RAND_CATEGORY PRIMARY KEY(cat_id,ver_num)
USING INDEX TABLESPACE VG_NDX ENABLE
)TABLESPACE VG_DATA';
Here's what I have so far:
EXECUTE IMMEDIATE 'CREATE TABLE RAND_CATEGORY(
-------- insert random vars ---------------
CONSTRAINT RAND_CATEGORY PRIMARY KEY(cat_id,ver_num)
USING INDEX TABLESPACE VG_NDX ENABLE
)';
My question is, should I remove the entire line:
USING INDEX TABLESPACE VG_NDX ENABLE
Or should I just remove the "TABLESPACE VG_NDX" and leave it as:
USING INDEX ENABLE
Keep in mind that I am new to this and I just need help with this. I have been learning SQL for the past 2 weeks and tablespaces are a bit funky to me. Thanks in advance! :D
Read this document:
http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_7003.htm
It provides a good overview of what tablespaces are and should solve the issue.
The USING INDEX clause allow to have more control over the constraint associated index creation, see http://docs.oracle.com/cd/B28359_01/server.111/b28310/indexes003.htm.
In your case the TABLESPACE storage clause.
If you want to let Oracle use the default tablespace you can remove the USING INDEX clause entirely leaving ENABLE.
Although in a CREATE TABLE a primary key constraint associated index is automatically enabled (unless I missed something) so I can't see any point of keeping the ENABLE.

is it possible to ignore some tablespaces when doing physical backup

We have a shell script that perform a physical backup of our oracle database (tar + compress of all our database files). Recently, we created a tablespace containing tables that we dont need to backup its contents.
Is it possible to ignore data files relative to this tablespace and have a valid backup?
PS: we don't want to use RMAN.
I preface my remarks here with a note: this is NOT the normative pattern. Normally, we use RMAN to backup ALL the datafiles in the database. With that said...
Yes, it may be possible to restore and recover the database from a backup with a m ssing datafile. But the recovery will require that the tablespace be dropped when the database is restored.
For the simple case of a dropping a tablespace that contains a single datafile: first restore the database files, then:
STARTUP NOMOUNT;
ALTER DATABASE MOUNT ;
ALTER DATABASE DATAFILE '<complete_path_to_datafile>' OFFLINE DROP ;
ALTER DATABASE OPEN ;
DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS ;
Then, continue with database recovery ( RECOVER DATABASE ; )
Obviously, the tablespace_name you provide in the DROP TABLESPACE command would be the one related to the datafile that is dropped.
Obviously, this wouldn't work for the SYSTEM tablespace. And I wouldn't dare try this on other tablespaces like UNDO, SYSAUX, USERS. And there's different syntax for dropping and adding TEMPORARY TABLESPACES.
I don't know of any "gotchas" with the 'DROP TABLESPACE ... INCLUDING CONTENTS', but consider that objects in other tablespaces could be impacted. (Consider that the dropped tablespace might have indexes for tables in other tablespaces, impacts on foreign key constraints, impacts on stored procedures, and so on.)
And it goes without saying, that you would need to test this type of restore procedure in a test environment before you rely on this technique in production.
Without testing, you would be much better served by using RMAN to backup ALL of the datafiles.
NOTE: I have not done anything like this since Oracle 8, possibly Oracle 7.3 (back when we had to roll our own hotbackup scripts). Since we've started using RMAN, I haven't had a need to test anything like this.
NOTE: The RECOVER DATABASE may need to be run before the ALTER DATABASE OPEN. I think you may get an exception warning about "datafile needing more recovery", like you do when you start the database when a tablespace has been left in BEGIN BACKUP mode...

Tablespace after Create Table. What does it mean?

Im reading some Oracle scripts, and I found one with this
Create Table XXY(...)
Tablespace SOME_TABLESPACE
....
NOCOMPRESS
NOPARALLEL
..
What does this mean? What is if for? There are many CreateTable statemsnts, but the Tablespace statement after is exactly the same.
As I understand SOME_TABLESPACE must exist when this script is excecuted, but thats all I could get. Is the purpose of the statement to store all the tables in the same place?
EDIT
I read this
http://www.adp-gmbh.ch/ora/concepts/tablespaces.html
"Same place" doesn't quite describe it ...
A tablespace is a grouping of common data files. With your "Create" statements you can define in which tablespace an object gets stored. Usually different types of oracle objects are stored in different tablespaces that can have different capabilities.
Some examples:
"Data" (your tables and the rows stored in these tables) are stored in a different tablespace than "system information" (such as transaction logs or "caches"). This allows you to store system information on a local drive (quick, but somewhat limited in space) and data in a Storage Area network (basically unlimited space, but not quite as fast).
Table Data and Indexes can be stored in different tablespaces which may be on different disks. Therefore, table lookup and index lookup can use different disks and be faster than if both were on the same disk.
Tablespaces and their different characteristics are oen of the many ways of tuning an Oracle DB. Lots of capabilities, lots of complexity. If all you're doing is a little development machine, there is little need to worry about it.
It creates the table in that tablespace. In the case of partitioned tables it defines that tablespace as the default for new partitions and subpartitions also.
Please read:
http://download.oracle.com/docs/cd/B10501_01/server.920/a96524/c04space.htm