I have an index in which I have to remove one column and reindex back for rebuild:
ALTER INDEX <index_name> REBUILD;
Is it possible to add partition when I rebuild an index. Partition will be based on one of the column index which is a datetime field. Something like:
ALTER INDEX <index_name> REBUILD, PARTITION BY RANGE(COLLECTIONTIME) INTERVAL (INTERVAL '15' MINUTE)
(PARTITION INITIAL_PARTITION VALUES LESS THAN (DATE '2014-10-10') );
Not sure how to write the sql statement for it. Anyone can help?
Also, if it is possible will the existing records will also be partitioned?
Edit: Database is Oracle
If you want to remove a column from an index which is on a partitioned table I assume the table is huge. This means the index rebuild takes time. You can either do an online rebuild or just create a new index and drop the old one afterwards.
If your index inherits the partition key column you can create a LOCAL, PREFIXED index on the table.
LOCAL means, each index partition has only records from one table partition -- table and index have the same partition structure
PREFIXED means, that the index inherits the partition key and supports partition pruning when the index is read.
The following command will create an index as mentioned above. The partitions are stored in the default tablespace of the user. The partition structure will be the same as the table.
create index <index_name> on (<columns>) LOCAL;
If you want the partitions to be stored in a different tablespace you can use this command:
create index <index_name> on (<columns>) LOCAL
(partition <index_name>_p1 tablespace whatever_1,
partition <index_name>_p2 tablespace whatever_2
);
Related
Is there a way to migrate a date sharded table to a partitioned table by ingestion time i.e _PARTITIONDATE and clustered by column?
I read https://cloud.google.com/bigquery/docs/creating-partitioned-tables#convert-date-sharded-tables and understand how to convert a date sharded table to a partitioned table by ingestion time. If after the conversion I edit the table to be clustered by a column than only new data uploaded to the table will be clustered, but I want the existing data to be clustered.
From https://cloud.google.com/bigquery/docs/creating-clustered-tables I find how to create a clustered table from an existing table only by using query result CREATE TABLE AS SELECT, but I can not create a partition by ingestion time when using the AS query_statement clause.
Is there a way to solve this and migrate my data to be partitioned by ingestion time and clustered by specified column?
I'm trying to drop an index created on a table, but I get this error -
The operation 'ALTER TABLE DROP INDEX' is supported only with memory optimized tables.
I need to remove this index in order to drop a field in my table. Is there any way of doing this without duplicating the table, and migrating all the data across?
For regular tables you should use DROP INDEX syntax:
DROP INDEX index_name ON tab_name;
ALTER TABLE
The syntax ALTER TABLE ... ADD/DROP/ALTER INDEX is supported only for memory-optimized tables.
To Drop an Index
DROP INDEX index_name ON table_name
To Add an Index
CREATE INDEX index_name ON table_name(column1, column2, ...);
Drop index on memory optimized table can be done only using alter table statement
Alter table table name DROP INDEX index name
or non memory optimized tables
DROP INDEX index name ON table name
Memory optimized tables are being supported from sql server 2016.
Look here: if it is NOT a memory optimized table then just use the "drop index" statement.
You need use
Drop Index <IndexName> On <TableName>
I have around 300 tables which are located in different partition and now these tables are not in use for such huge data as it was. Now, I am getting space issue time to time and some of but valuable space is occupied by the 150 filegroups that was created for these tables so I want to change table's filegroup to any one instead of 150 FG and release the space by deleting these filegroups.
FYI: These tables are not holding any data now but defined many constraints and indices.
Can you please suggest me, how it can be done efficiently ?
To move the table, drop and then re-create its clustered index specifying the new FG. If it does not have a clustered index, create one then drop it.
It is best practice not to keep user data on primary FG. Leave that for system objects, and put your data on other file groups. But a lot of people ignore this...
I found few more information on the ways of changing the FG group of existing table:
1- Define clustered index in every object using NEW_FG (Mentioned in #under answer)
CREATE UNIQUE CLUSTERED INDEX <INDEX_NAME> ON dbo.<TABLE_NAME>(<COLUMN_NAME>) ON [FG_NAME]
2- If we can't define clustered index then copy table and data structure to new table, drop old and rename new to old as below
Changes Database's default FG to NEW_FG so that every table can be created using INTO, under that new FG by default
ALTER DATABASE <DATABASE> MODIFY FILEGROUP [FG_NAME] DEFAULT
IF OBJECT_ID('table1') IS NOT NULL
BEGIN
SELECT * INTO table1_bkp FROM table1
DROP TABLE table1
EXEC sp_rename table1_bkp, table1
END
After all the operation Database's default FG as before
ALTER DATABASE <DATABASE> MODIFY FILEGROUP [PRIMARY] DEFAULT
3- Drop table if feasible then create it again using NEW_FG
DROP TABLE table1
CREATE TABLE [table1] (
id int,
name nvarchar(50),
--------
) ON [NEW_FG]
I have a clustered index on a table indexing on the text column. I want to switch that column with a different column like ID, how do I alter the index?
I can't drop and recreate because this is running on Azure and the table needs to have clustered index all the time.
The SQL command and the syntax for changing index columns in an index.
alter index ?
Try this:
create clustered index [your_index_name]
on [your_table]
([ID])
with (drop_existing = on)
You cannot alter a clustered index.
The only option is to drop it and re-create it with the new column.
In your case, you'll probably have to re-create the table with the new clustered index on ID and then copy the data over.
This can be a silly question but I want to be sure 100%.
Is the PK of a DB2 table a clustered index by default?
From: DB2 docs - Clustering indexes
Although a table can have several indexes, only one index can be a clustering index. If you do not define a clustering index for a table, DB2 recognizes the first index that is created on the table as the implicit clustering index when it orders data rows.
So no, by default the Primary Key is NOT the clustered index of the table.
The first created index, unique or not, is the "implicit" clustering index and DB2 tries to insert the records as nearly as possible in the order of the values of this index.
If you later create another index and identify it as clustering, then DB2 identifies it as the clustering index but does not rearrange the data that is already in the table. This can be done with the REORG utility.
From the Publib (this assumes DB2 for z/OS, version 9)
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.
You can see which index is the clustering index for a table (in this example, TEST.TABLE1) using the following query, if you're on z/OS:
SELECT NAME
FROM SYSIBM.SYSINDEXES
WHERE TBCREATOR = 'TEST'
AND TBNAME = 'TABLE1'
AND CLUSTERING = 'Y'
And this one for Linux/Unix/Windows (LUW):
SELECT *
FROM SYSCAT.INDEXES
WHERE TABSCHEMA = 'TEST'
AND TABNAME = 'TABLE1'
AND INDEXTYPE = 'CLUS'
DB2 doesn't create clustered index for a PK by default.
Primary keys
A primary key is a special type of unique key and cannot contain null values. For example, the DEPTNO column in the DEPT table is a primary key.
A table can have no more than one primary key. Primary keys are optional and can be defined in CREATE TABLE or ALTER TABLE statements.
The unique index on a primary key is called a primary index. When a primary key is defined in a CREATE TABLE statement or ALTER TABLE statement, DB2 automatically creates the primary index if one of the following conditions is true:
DB2 is operating in new-function mode, and the table space is implicitly created.
DB2 is operating in new-function mode, the table space is explicitly created, and the schema processor is running.
DB2 is operating in conversion mode, and the schema processor is running.
If a unique index already exists on the columns of the primary key when it is defined in the ALTER TABLE statement, this unique index is designated as the primary index when DB2 is operating in new-function mode and implicitly created the table space.
See at: Keys DB2