I have a table with some indexes and they are dependent on some columns.
These columns are of type smallint and I want to alter them to decimal.
Here is the question: if I alter the columns, does it effect the index performance?
(I know I can't alter the columns with dependencies).
Altering the datatype of the column will Rebuild the indexes as well. So your index performance wouldn't be affected.
Related
As part of a system upgrade, we need to be able to update a database structure to conform to the newest version.
I'm writing a tool to that end, but am stuck on the correct procedure for updating a column which is used in an index.
If a column which is in an index must be changed, which approach is likely to be the least problematic:
1) Disable the index, alter the column, re-enable the index
2) Drop the index, alter the column, re-create the index
There are a number of instances where this change must be applied, and I would like to reduce the overall time as much as possible, hence my preference for not recreating the index if it can be avoided.
I did some tests,it seems you cannot alter index columns .
test data:
create table idd
(
id int identity(1,1),
name char(33),
name2 varchar(40) null
)
create unique clustered index nci_id on idd(id)
create index nci_test1 on idd(name2)
--disable index
alter index nci_test1 on idd disable
--alter column
alter table idd
alter column test1 varchar(100) not null
below is the error:
Msg 5074, Level 16, State 1, Line 36
The index 'nci_test1' is dependent on column 'test1'.
Msg 4922, Level 16, State 9, Line 36
ALTER TABLE ALTER COLUMN test1 failed because one or more objects access this column.
This is obvious since I have clustered key.so what happens if I drop clustered key and then do an alter operation on non clustered index key column,Result is same.We can alter index columns only after dropping them
drop index [nci_id] on idd
--alter column
alter table idd
alter column test1 varchar(100) not null
I think you got some idea on what is the impact
1.We have to drop clustered key first ..heavy tlog writes,since non clustered key also have to change there pointers
2.Again we have to rebuild indexes
You can only drop them.Further I would suggest you go ahead with this approach(since either way you have to drop clustered index) of
1.Drop index
2.Alter column datatype
3.recreate index
Further try changing database recovery model to simple,so as to minimize TLOG writes prior to this operation and also add nocheck option .Below questions has some interesting answers which may help you
https://dba.stackexchange.com/questions/48872/quickly-change-null-column-to-not-null
How do you add a NOT NULL Column to a large table in SQL Server?
I am trying to change datatype of a column in SQL Server from INT to BIGINT.
ALTER TABLE Table1 ALTER COLUMN ID BIGINT
However, it is giving me below error:
ALTER TABLE failed because the following SET options have incorrect settings: 'ANSI_WARNINGS'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations.
I checked the Table1 and there is just 1 computed column (i.e. cost * quantity kind off). There are no indexes on this particular column. Neither there is any index on ID column. The ID column of Table1 is not referred elsewhere in any other table. I tried changing ANSI_Warnings ON and OFF but still gives same error.
So I am not sure where the problem is. Any help appreciated!
I was doing the same thing the OP - alter the PK from INT to BIGINT on 2 tables. In first table it went smoothly, in second table I got same error as OP:
ALTER TABLE failed because the following SET options have incorrect
settings: 'ANSI_WARNINGS'. Verify that SET options are correct for use
with indexed views and/or indexes on computed columns and/or filtered
indexes and/or query notifications and/or XML data type methods and/or
spatial index operations.
Running SET ANSI_WARNINGS ON or OFF is not helping.
The steps are:
drop indexes
drop PK constraint
drop persisted columns
run ALTER TABLE [table] ALTER COLUMN [id] BIGINT
create persisted columns, indexes, PK constraint back as they were
To get rid of the error, there's one thing I had to do differently in step 1:
in first table it was OK to drop just indexes using the changed column, keep other indexes
in second table I had to drop all indexes, even those not using the column
Probably because your column is the Primary Key and indexed as the CLUSTERED index, then used by every NONCLUSTERED indexes...
So drop NONCLUSTERED indexes and the PK, execute the ALTER TABLE and then add the PK and all NONCLUSTERED indexes that you have dropped.
I've increased the width of a column from varchar(8) to varchar(10). Do I need to drop index of this column and recreate it?
No need to drop and recreate index - because it's meta data change only.
check below link for reference.
Reference
I'm not very sure I get your question. In case you have a non-clustered index on that column => you cannot change datatype of the column before dropping the index.
Why? Because it has to allocate more space to the index.
An alternative would be:
1/ Disable the index:
ALTER INDEX <indexname> ON <tablename> DISABLE;
2/ Change datatype of the column
ALTER TABLE <tablename> ALTER COLUMN <columnname> varchar(10) NOT NULL;
3/ Rebuild index (there is no ALTER INDEX... ENABLE):
ALTER INDEX <indexname> ON <tablename> REBUILD;
I'm attempting to align an index with a partitioned table, but the partition key column is nullable in the table definition.
In order to align the indexes I have to make this field not null, but when I attempt to alter the column on the table I receive an error saying that the table depends on that field.
You will need to remove the partition scheme from that table, correct the data issue, then repartition.
Or, create a new, properly partitioned version of the table with the right constraints and put your data into it from the old table.
I am mass updating a SQL Server database. I am changing all our numeric(38,0) columns to int (yes, SQL Server scripts were created from Oracle scripts).
Using SMO and C# (I am a sw engineer), I managed to generate really nice scripts like SQL Server Management Studio would.
It all works very nicely except for one particular issue:
For a handful of tables, when I call
ALTER TABLE [myTable] ALTER COLUMN [columnA] INT
it decides to also change the column from NOT NULL to NULL. That, of course is a huge issue since I need to regenerate primary keys for most of those tables on those particular columns.
Obviously, I have plenty of options using SMO to find out which columns are primary keys and force them to be NOT NULL after or while I am updating the data type, but I am really curious as to what can be causing this.
Regards,
Eric.
Because in the absense of NOT NULL, the default is NULL.
ALTER TABLE [myTable]
ALTER COLUMN [columnA] INT NOT NULL
from ALTER TABLE (Transact-SQL)
When you create or alter a table with
the CREATE TABLE or ALTER TABLE
statements, the database and session
settings influence and possibly
override the nullability of the data
type that is used in a column
definition. We recommend that you
always explicitly define a column as
NULL or NOT NULL for noncomputed
columns.