I've checked index type in one of my table and found that all indexes are of type REG (non clustered). As per DB2 documentation, DB2 by default use the first index created as clustered index if not explicitly specified. Why DB2 is showing all of my indexes as REGULAR?
Reference: http://www-01.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.intro/src/tpc/db2z_clusteringindexes.dita
"When a table has a clustering index, an INSERT statement causes DB2 to insert the records as nearly as possible in the order of their index values. The first index that you define on the table serves implicitly as the clustering index unless you explicitly specify CLUSTER when you create or alter another index. For example, if you first define a unique index on the EMPNO column of the EMP table, DB2 inserts rows into the EMP table in the order of the employee identification number unless you explicitly define another index to be the clustering index"
Here is my understanding of your question - You read on the IBM documentation website that
DB2 by default use the first index created as clustered index if not explicitly specified
and your question is that you saw your DB2 9.7 LUW database and saw only REG indexes.
#mustaccio is correct. DB2 LUW never creates clustered indexes by default.
As per DB2 9.7 LUW documentation here, it says
clustering indexes cannot be specified as part of the table definition
used with the CREATE TABLE statement. Instead, clustering indexes are
only created by executing the CREATE INDEX statement with the CLUSTER
option specified. Then the ALTER TABLE statement should be used to add
a primary key that corresponds to the clustering index created to the
table. This clustering index will then be used as the table's primary
key index.
And #Ian Bjorhovde is also correct, you are reading DB2 for z/OS documentation. There are many differences between DB2 LUW and DB2 for z/OS
Related
I can use the pg_indexes view to get the SQL used to create an index (as in the sql in this question: How to get indexes, primary keys, and all constraints for a schema in PostgreSQL using standard sql).
Is there a way to get the SQL for constraints in PostgreSQL? I'm not seeing a pg_constraints table and the information I'm finding on line isn't pointing me to a solution, for example, these are some of the hits coming up when I Google the terms (postgresql get sql for constraint).
https://dba.stackexchange.com/questions/206562/postgres-read-constraints-definition
Postgres Check Constraint definition
https://www.geeksforgeeks.org/sql-query-to-display-all-the-existing-constraints-on-a-table/
I created a database on db2 11.5, then tablespace, then create a table. Everything okay so far.
However, when i tried to create index in the newly created TABLESPACE, it complains syntax error:
CREATE INDEX SCH.TBL_CAT_ERR_NIX01 ON SCH.TBL_CAT_ERR (CAT_NO ASC, CAT_ERR_ID ASC) in TBS_CAT_SINDEX;
with error:
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0109N The statement or command was not processed because the following
clause is not supported in the context where it is used: "IN". SQLSTATE=42601
i tried these 2 but still they don't work, complaining the "PARTITION" clause is not supported
CREATE INDEX SCH.TBL_CAT_ERR_NIX01 ON SCH.TBL_CAT_ERR (CAT_NO ASC, CAT_ERR_ID ASC) partitioned in TBS_CAT_SINDEX;
CREATE INDEX SCH.TBL_CAT_ERR_NIX01 ON SCH.TBL_CAT_ERR (CAT_NO ASC, CAT_ERR_ID ASC) not partitioned in TBS_CAT_SINDEX;
Could you help me pointing out what I'm missing?
When you run your create table statement, you can optionally specify the index in clause at that time to allow indexes to use a specific tablespace that you pre-created. Additional capabilities are available for PARTITIONED tables.
The key detail you omitted from your question was whether or not your table is itself partitioned.
The documentation for create index states that the IN tablespapace-name clause can only be specified or a nonpartitioned index on a partitioned table. So if your table is not itself partitioned then you cannot use this IN clause when creating an index, and you should consider using the create table statement to identify an index tablespace for that table instead.
In Oracle, if we try to create two indexes on same column of same table then it gives ORA-01408: such column list already indexed.
create index tmp_idx1 on student(roll_no);
create index tmp_idx2 on student(roll_no);
ORA-01408: such column list already indexed.
But, same if we try to create in Postgres, it allows.
How can we stop this in postgres and make behavior like in Oracle?
We have got some DDLs for our schema. These DDLs create tables and indexes in a given tablespace. Something like:
CREATE TABLE mySchema.myTable
(
someField1 CHAR(2) NOT NULL ,
someField2 VARCHAR(70) NOT NULL
)
IN MY_TBSPC
INDEX IN MY_TBSPC;
We want to reuse this DDLs to run some integration tests using APACHE DERBY. The problem is that such syntax is not accepted by DERBY. Is there any way to define a kind of default tablespace for tables and indexes, so we can remove this 'IN TABLESPACE' statements.
There is no deterministic way of defining a "default" tablespace in DB2 (I'm assuming we're dealing with DB2 for LUW here). If the tablespaces are not explicitly indicated in the CREATE TABLE statement, the database manager will pick for table data the first tablespace with the suitable page size that you are authorized to use, and indexes will be stored in the same tablespace as data.
This means that if you only have one user tablespace it will always be used for both data and indexes, so in a way it becomes the default. However, if you have more than one tablespace with different page sizes you may end up with tables (and their indexes) in different tablespaces.
How to create indexes on MQT(materialized query table) in Db2? I haven't found this information in documentation? Is index creation syntax the same as for common tables?
After you create your MQT you have to refresh the table before you can create indexes. However, at this point it's exactly the same as creating indexes on a normal table.
There are some limitations on what type of indexes you can create on an MQT. For example, it cannot be a unique index.