1.heap table
IOT
PARTITION TABLE
HEAP TABLE
CLUSTER
2.create table t(
id number,
varchar2(80),
name char2(10)
)
pctfree 20
pctused 40
storage(
initial 180k
next 180k
pctincrease 10
miniextents 3
maxextents 5
)
tablespace users
create global temporary table temp(id number,name char(10));
alter table t pctfree 30 pctused 40 storage(initial 180k next 180k minixtents 3 maxextents 5);
alter table t allocate extent(size 600k datafile '/u01/oradata/lsh/data01.dbf');
alter table t move tablespace user1;
truncate table t // no generation undo log,ddl ,can not truncate the table which have refer.realease space. index are truncate
truncate table t reuse storage;
drop table t
alter table t drop column name cascade constraints checkpoint 1000;
alter table t drop columns continue;
alter table t set unused column name cascade constraints;
alter table t dop unused columns checkpoint 1000
alter table t dop columns continue checkpoint 1000
alter table t rename column name to vname
select dbms_metadata.get_ddl('TABLE','T') from dual;
select * from user_object;
select * from user_tables;
1.HEAP TABLE:
Oracle will place the data where it fits, not in any order by date or transaction
You should think of a heap organized table as a big unordered collection of rows. These
rows will come out in a seemingly random order, and depending on other options being used
(parallel query, different optimizer modes, and so on), they may come out in a different order
with the same query. Do not ever count on the order of rows from a query unless you have an
ORDER BY statement on your query!
2.IOT:
Index organized tables (IOTs) are, quite simply, tables stored in an index structure.
We have to make room for both the table and the index on the primary key of the table when using a heap organized table. With an IOT, the space overhead of the primary key index is removed, as the index is the data and the data is the index.
When you want to enforce co-location of data or you want data to be physically stored in a specific order, the IOT is the structure for you.
• Increased buffer cache efficiency, as any given query needs to have fewer blocks in the
cache
• Decreased buffer cache access, which increases scalability
• Less overall work to retrieve our data, as it is faster
• Less physical I/O per query possibly, as fewer distinct blocks are needed for any given
query and a single physical I/O of the addresses most likely retrieves all of them (not
just one of them, as the heap table implementation does)
Each I/O and each consis-tent get requires an access to the buffer cache, and while it is true that reading data out of the buffer cache is faster than disk, it is also true that the buffer cache gets are not free and not totally cheap. Each will require many latches of the buffer cache, and latches are serialization devices that will inhibit our ability to scale.
3.