In SQL Server 2016, I want to move ALL Clustered indexes in a DB to a secondary filegroup. What's the easiest way to do this?
This question is only for Nonclustered Indexes.
Moving all non-clustered indexes to another filegroup in SQL Server
Note: Want to retain Nonclustered indexes in same filegroup, and prevent creating additional unique indexes on primary key
In the process of optimizing an older legacy database
Related
I have to migrate SQL Sever 2008 database to the SQL Server 2012. 2008 is the enterprise version and 2012 is standard version. As we know, standard version does not support table partitioning.
The table which is partitioned in the enterprise version has 1 clustered and around 8 non-clustered indexed. I need to drop this partition but do not know how. Can someone please shed little light on how should I go about it?
Thanks.
To unpartition a table, you'll need to recreate all the indexes with a filegroup specification instead of parttion scheme. I suggest you drop all the non-clustered indexes and then rebuild the existing partitioned clustered index using CREATE INDEX...WITH(DROP_EXISTING-ON) with a filegroup specification. Then recreate the non-clustered indexes with a filegroup specfied.
I want to have an automatically updated structure in SQL Server that can handle aggregate queries well. Can I create an indexed view in SQL server 2014 that has a columnstore index as its clustered index?
You can't create a columnstore index on a view as per the documentation:
CREATE COLUMNSTORE INDEX (Transact-SQL)
In the limitations and restrictions it explicitly states:
"Cannot be created on a view or indexed view."
Can we create clustered/non-clustered columnstore index on a memory optimized table in SQL Server 2014?
Columnstore Index is not supported with memory optimized tables.
Nope, you can't create a columnstore index on a memory optimized table, only nonclustered hash and nonclustered indexes are allowed, see here for more details:
Guidelines for Using Indexes on Memory-Optimized Tables
ColumnStore indexes are going to be supported on Top on In-memory/hekaton tables in SQL Server 2016.
I have a database that will be used by multiple clients (local installs), the plan is to then copy the data to Azure to allow global reporting etc.
The database will be using GUIDs for it's primary keys.
What should I use for a clustered index on the tables, or does that not matter when adding data to Azure? Do I even really need a clustered index? Azure will have single copy of the database, with all client data in it if that makes a difference.
thanks all.
Although you are allowed to create (and have data in) a table without clustered index in SQL Server, this is not allowed in Windows Azure SQL Database ( WASD / SQL Azure). While you can have the table without clustered index in WASD as definition, no DML statement will be allowed to execute against such a table, i.e. you will not be able to do INSTERT/UPDATE/DELETE statements against table in WASD without clustered index. So, if by any chance data is going to the cloud, you should have a clustered index. For more info, check the Clustered Index Requirement in the Guildelines and limitations for Windows Azure SQL Database.
Some of the recommendations here are incorrect.
NEWSEQUENTIALID() is not allowed on SQL Azure.
In SQL Azure, a clustered index is absolutely required. You can create a table
without one, but you will not be able to add data to it until after
you add the clustered index.
In Azure, the clustered index is used for their back-end replication. Reference: http://blogs.msdn.com/b/sqlazure/archive/2010/05/12/10011257.aspx
I think that your best bet is to use a column with an Identity element as the clustered index, along with a non-clustered index on your guid column. I ran into this exact same problem and after quite a bit of research, it's the solution I eventually came up with. It's a bit of a pain to put together, especially if you already have data in production on Azure, but it seems to be the one that addresses all of the issues.
I feel like it would be simplest to use a NEWSEQUENTIALID, but that isn't an option on Azure.
I need to combine files in a filegroup in SQL Server 2005. How do I do this? I've run the EMPTYFILE DBCC Shrinkfile but it's crawling..
One way (for the tables at least) would be to drop the clustered index and then re-create the clustered index specifying the filegroup you are trying to combine them into. Since the clustered index is applied to the actual table this would accomplish what you are trying to do (for the tables).
You can read more about this approach on this MSDN forum topic.
http://social.msdn.microsoft.com/Forums/en-US/sqlreplication/thread/043c2bd4-07a1-4361-8c2b-7f375dd72107