PL/SQL Creating a table with indexes - oracle

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.

Related

In which order should we apply primary key, foreign key constraints and create index if the Oracle table has data?

1.In which order should we apply primary key, foreign key constraints and create index if the Oracle table has millions of data and does not have prior constraints?
2.Can we use 'NOLOGGING PARALLEL' while applying primary key and foreign key constraints like we do while applying(creating) indexes? Or any other method so that primary key and foreign key constraints could be applied faster?
Note: I'll use bullets so that it is easier to read, as it is easy to get lost in long sentences.
My thoughts on the subject; see if anything of this helps.
Well,
as you can't create a foreign key constraint if column(s) it references aren't part of primary or unique key
you'll obviously first have to create primary key constraints
and then foreign key constraints
When you
create a primary key constraint,
Oracle automatically creates index that supports it, unless there's already an index you can use (with the USING INDEX clause)
which means that you can "skip" some indexes (those for primary key constraints as they'll already exist) and virtually save some time
and create "other" indexes
On the other hand,
if you first create unique index on future primary key columns and
later add primary key constraint with the USING INDEX clause, Oracle will "skip" check for possible duplicate values because unique index won't allow them
The same goes for
NOT NULL constraint on future primary key columns; primary key doesn't allow NULLs so - if a column already is NOT NULL, enforcing primary key constraint can skip NULL check as well
I don't know
which columns you'll additionally index, but - as you're on Oracle 11g -
don't forget to index all foreign key constraint columns
because you might encounter unexpected table locks if you
update primary key column in parent table, or
delete parent record
Can you do it with no logging and in parallel? Yes:
SQL> create table test (id number, name varchar2(20));
Table created.
SQL> create unique index ui1_test_id on test (id) nologging parallel 20;
Index created.
SQL> alter table test add constraint pk_test primary key (id) using index ui1_test_id nologging parallel 20;
Table altered.
SQL>
But you'll probably want to change the index and table back to NOPARALLEL and LOGGING when the initial creation is done.
SQL> alter index ui1_test_id noparallel;
Index altered.
SQL> alter table test logging noparallel;
Table altered.

What is the disadvantage of using SHRINK SPACE for an Oracle Table?

I am going to develop a reporting database by querying the production database once using a stored procedure.
The stored procedure will then write the result into it's own output tables.
Following is the schema for the output table:
Create table Output (
Customer_ID NUMBER(15) not null,
STD_HASH RAW(1000 BYTE) ,
VALID_PERIOD_START NOT NULL TIMESTAMP(6),
VALID_PERIOD_END NOT NULL TIMESTAMP(6),
Address VARCHAR2(30 CHAR),
period for valid_period(valid_period_start,valid_period_end),
Constraint Output_PK Primary Key ( Customer_ID, valid_period_start, valid_period_end )
)
As the stored procedure will perform a lot of update and delete statement on the output table, and those output table is very big. The largest one I have right now is 8GB. I am thinking to alter those output tables with the "SHRINK SPACE" option at the end of the stored procedure to reclaim some spaces.
Following is the statement that I am going to apply:
Alter table OUTPUT1 ENABLE ROW MOVEMENT; -- Temporary enable row movement for the table
Alter TABLE output2 SHRINK SPACE;
Alter table OUTPUT1 DISABLE ROW MOVEMENT;-- Disable row movement.
Those output tables are temporal table that is using the valid period and the ID from production as a primary key.
However, as I am very new with the Shrink Space function. Can anyone tell me what is the disadvantage of using this function?
The table, basically will not be updated from anywhere other than this stored procedure. The stored procedure will be scheduled to run in a daily base.
Thanks in advance!
yes, shrink has some restrictions:
(1) it locks the table during the shrink operation
(2) it change the rowid of the table.
(3) it needs the tablespace with automatic segment-space management enabled.
we have other alternatives to claim the unused space:
(1) export/import
(2) dbms_redefinition

Oracle Automatic LIST partition using virtual column not allowing REFERENCE partition on child table

I’ve made an attempt to create partition on test table using virtual column. This approach is working good for PARENT or standalone tables. However, I cannot create REFERENCE partition on CHILD table if the PARENT table is PARTITIONED using virtual column. I get the following error on create table of CHILD table
ORA-14659: Partitioning method of the parent table is not supported
Oracle Version details:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
PL/SQL Release 12.2.0.1.0 - Production
Please find the script below.
--######################PARENT TABLE###########################################
DROP TABLE BILL_HEADER_TST;
CREATE TABLE BILL_HEADER_TST
(
BILL_HDR_SID NUMBER (30) NOT NULL,
TCN VARCHAR2 (21 BYTE) NOT NULL,
TCN_DATE DATE,
PROGRAM_CID NUMBER,
CONSTRAINT XPKBILL_HEADER_TST PRIMARY KEY (BILL_HDR_SID),
PARTN_KEY NUMBER
AS ( PROGRAM_CID
|| TO_NUMBER (TO_CHAR (TCN_DATE, 'YYYYMM')))
VIRTUAL
)
PARTITION BY LIST (PARTN_KEY) AUTOMATIC (PARTITION PDEFAULT VALUES (1201401));
------------------LOCAL INDEXES------------------------------------------------
CREATE INDEX XIE33BILL_HEADER_TST
ON BILL_HEADER_TST (TCN_DATE)
LOCAL;
CREATE INDEX XIE38BILL_HEADER_TST
ON BILL_HEADER_TST (PROGRAM_CID)
LOCAL;
---------------------INDEXES---------------------------------------------------
CREATE UNIQUE INDEX XAK1BILL_HEADER_TST
ON BILL_HEADER_TST (TCN)
LOGGING
NOPARALLEL;
--#############CHILD TABLE#####################################################
DROP TABLE BILL_LINE_TST;
CREATE TABLE BILL_LINE_TST
(
BILL_LINE_SID NUMBER (30) NOT NULL,
BILL_HDR_SID NUMBER (30) NOT NULL,
CLM_TYPE_CID NUMBER (3),
PROGRAM_CID NUMBER,
CONSTRAINT XPKBILL_LINE_TST PRIMARY KEY (BILL_LINE_SID),
CONSTRAINT XFK17_BILL_LINE_TST FOREIGN KEY
(BILL_HDR_SID)
REFERENCES BILL_HEADER_TST (BILL_HDR_SID) ON DELETE CASCADE
)
PARTITION BY REFERENCE (XFK17_BILL_LINE_TST)
ENABLE ROW MOVEMENT;
From the SQL Language manual
Automatic list partitioning is subject to the restrictions listed in "Restrictions on List Partitioning". The following additional restrictions apply:
An automatic list-partitioned table must have at least one partition
when created. Because new partitions are automatically created for
new, and unknown, partitioning key values, an automatic
list-partitioned table cannot have a DEFAULT partition.
Automatic list partitioning is not supported for index-organized
tables or external tables.
Automatic list partitioning is not supported for tables containing
varray columns.
You cannot create a local domain index on an automatic
list-partitioned table. You can create a global domain index on an
automatic list-partitioned table.
An automatic list-partitioned table cannot be a child table or a
parent table for reference partitioning.
Automatic list partitioning is not supported at the subpartition
level.

ORACLE EXCHANGE PARTITION and PARTITION INDEXES

In order to compress the data in a single partition, I use the following approach:
-- I create a table with the same structure of the ORIGINAL TABLE, but
-- on a new tablespace (NEW_TBS_DATA)
CREATE TABLE AUXILIARY_TABLE TABLESPACE NEW_TBS_DATA AS
SELECT * FROM ORIGINAL_TABLE WHERE 1=0
-- I create the index on the AUXILIARY_TABLE, on a new tablespace
-- for indexes (NEW_TBS_IDX)
CREATE INDEX I_1 ON AUXILIARY_TABLE( START_DATE) TABLESPACE NEW_TBS_IDX
CREATE INDEX I_2 ON AUXILIARY_TABLE( ID_FILE) TABLESPACE NEW_TBS_IDX
CREATE INDEX I_3 ON AUXILIARY_TABLE( DESCRIPTION) TABLESPACE NEW_TBS_IDX
CREATE INDEX I_4 ON AUXILIARY_TABLE( ZIP_CODE) TABLESPACE NEW_TBS_IDX
CREATE INDEX I_5 ON AUXILIARY_TABLE( BH_TRAFFIC) TABLESPACE NEW_TBS_IDX
-- I move data from partition 20160529 to auxiliary_table
ALTER TABLE ORIGINAL_TABLE EXCHANGE PARTITION PARTITION_20160529 WITH TABLE AUXILIARY_TABLE INCLUDING INDEXES WITHOUT VALIDATION
-- I compress data using the new tablespace NEW_TBS_DATA on auxiliary_table
ALTER TABLE AUXILIARY_TABLE MOVE TABLESPACE NEW_TBS_DATA PARALLEL 4 COMPRESS
-- I move the data back to the original table, with the same exchange statement:
ALTER TABLE ORIGINAL_TABLE EXCHANGE PARTITION PARTITION_20160529 WITH TABLE AUXILIARY_TABLE including indexes without validation
-- I drop the auxiliary_table
DROP TABLE AUXILIARY_TABLE CASCADE CONSTRAINTS PURGE
Why, at the end of the process, the partition INDEXES are on the old tablespace instead of the new tablespace (NEW_TBS_IDX)?
Section "including indexes" takes affect only for local indexes. See
https://docs.oracle.com/cd/E11882_01/server.112/e25523/part_admin002.htm
section(Exchanging Partitions)

list partitioning in oracle tables

I have created a table with default partitioning, Now I am adding another partition/subpartition then I am getting oracle error
CREATE TABLE STR_MAINFRAME_DB
(
CATEGORY VARCHAR(100) NOT NULL,
SUBCATEGORY VARCHAR(100) NOT NULL
)
PARTITION BY LIST (CATEGORY)
SUBPARTITION BY LIST (SUBCATEGORY)
(
PARTITION P_DUMMY VALUES (DEFAULT)
(
SUBPARTITION S_P_DUMMY VALUES (DEFAULT)
));
I am adding one more partition by using below SQL but it is throwing an error.
alter table str_mainframe_db add partition p_1 values ('A');
SQL Error: ORA-14323: cannot add partition when DEFAULT partition exists
14323. 00000 - "cannot add partition when DEFAULT partition exists"
*Cause: An ADD PARTITION operation cannot be executed when a partition
with DEFAULT values exists
Please help?????????
You cannot partition an existing table.
You will need to create a new, partitioned table and then move the data from the old table to the new. Then you can drop the old table and rename the new one to use the old table's name.
Depending on your downtime window and the nature of your application's access to data, you may want to use the dbms_redefinition package to manage this. It will like take more time than doing it manually but the overhead it imposes allows the old table to be kept online while the new table is being populated.

Resources