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
Related
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
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 have read through all the available documentations about file table on SQL server. One thing it has not mentioned is creating additional indexes (non-unique clustered index in my case) on a file table fixed schema.
Am I right to say it is perfectly fine to do that and it wouldn't cause any issues? If it is an issue what is the best approach?
According to the Create, Alter, and Drop FileTables topic in the SQL Server documentation (emphasis mine):
Since a FileTable has a pre-defined and fixed schema, you cannot add or change its columns. However, you can add custom indexes, triggers, constraints, and other options to a FileTable.
So you should be fine adding custom indexes.
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.
Sorry for my English.
There is database on SQL Server 2005 Enterprise. I wrote program which splits all tables on fileGroups by datetime. But the problem is that database schema is not designed for it and most information stays on the PRIMARY filegroup.
Please tell me how I can spread (split) tables onto two or more database servers for increased performance?
Are you looking for the syntax on how to move a table from one file group to another? See ALTER TABLE
ALTER TABLE dbo.MyTable
MOVE TO MyNewFileGroup
It sounds to me like you need to look into MS SQL Server's partitioning capabilities. You should not be doing this manually. Let the database solve that issue for you.