Why my mdf file from new filegroup not growing? - sql

I create a draft database with 2 tables: dbo.D and dbo.F, next I create a new filegroup for dbo.F and a file for this.
USE DEV
ALTER DATABASE DEV
ADD FILEGROUP [BLOB]
ALTER DATABASE DEV
ADD FILE
(
NAME= 'blob',
FILENAME = 'D:\MS SQL\DB\blob.mdf'
)
TO FILEGROUP [BLOB]
Next, I drop clustered index and recrete it, specifying a filegroup name.
ALTER TABLE F
DROP CONSTRAINT [F_PK] WITH (MOVE TO BLOB)
ALTER TABLE F
ADD CONSTRAINT [F_PK] PRIMARY KEY CLUSTERED
(
ID
)
WITH (IGNORE_DUP_KEY = OFF) ON BLOB
CREATE UNIQUE CLUSTERED INDEX F_PK
ON dbo.F(ID)
WITH DROP_EXISTING
ON [BLOB]
Next, I create more then 2k INSERT's queries and full in dbo.F with random binary data.
Question!
Why on this picture my new filegroup's file weighs so little unlike in the default filegroup's file?

Without seeing the full schema of your tables... you only have ID in your clustered index which means that all of the data you inserted is still in your primary filegroup. The only thing in blob is the index of your ID values which I would assume is not going to be anywhere near as large as the binary data you are inserting. I'm basing my assumption on ID being an INT column...
This, of course, is irrelevant if ID is the column in which you are storing your binary data, but I assume that's not the case if you're using it as a PK and clustered index.

Related

Efficient way to change the table's filegroup

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]

Partition scheme change with clustered Index

I have table which has 600 million records and also has the Partition on PS_TRPdate(TRPDate) column, I want to change it to another Partition PS_LPDate(LPDate).
So I have tried with small amount of data with following steps.
1) Drop the Primary key Constraints.
2) Adding the New Primary Key Clustered Index with new Partition PS_LPDate(LPDate).
Is it Feasible with 600 million records? Can anyone guide me for it?
and How does it works with Non Partitioned Tables?
--343
My gut feeling is that you should create a parallel table using a new primary key, file groups and files.
To test out my assumption, I looked at a old blog post in which I stored the first five million prime numbers into three files / file groups.
I used the TSQL view that Kalen Delaney wrote and I modified to my standards to look at the partition information.
As you can see, we have three partitions based on the primary key.
Next, I drop the primary key on the my_value column, create a new column named chg_value, update it to the prime number, and then try to create a new primary key.
-- drop primary key (pk)
alter table tbl_primes drop constraint [PK_TBL_PRIMES]
-- add new field for new pk
alter table tbl_primes add chg_value bigint not null default (0)
-- update new field
update tbl_primes set chg_value = my_value
-- try to add a new primary key
alter table tbl_primes add constraint [PK_TBL_PRIMES] primary key (chg_value)
First, I was surprise that the partition still stayed together after dropping the PK. However, the view shows the index no longer exists.
Second, I end up receiving the following error during constraint creation.
While you could merge/switch the partitions into one file group which is not part of the scheme, drop/create the primary key, partition function & partition scheme, and then move the data yet again with the appropriate merge/switch statements, I would not.
This will generate a ton of work (TSQL) and cause alot of I/O on the disks.
I suggest you build a parallel partitioned table, if you have space, with the new primary key. Reload the data from the old table to the new.
If you are not using data compression and have the enterprise version of SQL Server, why not save the bytes by turning it on.
Good luck!
John
www.craftydba.com

Alter clustered index column

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.

Set identity off in azure sql table

I have a table which includes an identity column but i cant remove the identity property.
Is there a way to disable it? Or a way to make a copy of the entire table without identity property?
Note that you may not be able to drop the column if it referenced by a clustered index, and you can't drop all clustered indexes for a table because SqlAzure tables must always have a clustered index.
This means that you may have to jump through the following hoops (for at least your last clustered index, which may well be your primary key):
rename your clustered index
create a temp version of the table (with a new clustered index)
copy the data from the current table
drop the current table
rename the temp table to the current name
This roughly looks like this:
-- Rename clustered index
EXECUTE sp_rename N'PK_My_Current_PK', N'PK_My_Current_PK_OLD', 'OBJECT'
-- If you have any FK constraints on the table, then drop them
ALTER TABLE dbo.MyTable DROP CONSTRAINT FK_My_Foreign_Key
-- Create the new version of your table - because this is SQLAzure it must have a clustered index
CREATE TABLE dbo.tmp_MyTable (
MyID int NOT NULL,
CONSTRAINT PK_My_Current_PK PRIMARY KEY CLUSTERED (MyID)
)
-- Copy the data into the temp table from the old table
INSERT INTO dbo.tmp_MyTable (MyID)
SELECT MyID FROM dbo.MyTable
-- Drop the old table
DROP TABLE dbo.MyTable
-- Rename the new table
EXECUTE sp_rename N'tmp_MyTable', N'MyTable', 'OBJECT'
-- Recreate any foreign key constraints
ALTER TABLE dbo.MyTable WITH CHECK ADD FK_My_Foreign_Key FOREIGN KEY (MyID)
REFERENCES dbo.MyForeignTable (MyID)
Hope that helps
A
Edit: As #PhilBolduc pointed out SqlAzure tables require a clustered index, not a primary key. I've amended the terminology above accordingly - the principle of the answer still remains.
You can not remove an Identity column without dropping it unfortunately. Alternetivly add a new column with a temp name, update the new column value and then drop the previous column.
ALTER TABLE dbo.tablename ADD newcolumnname INT
UPDATE dbo.tablename SET newcolumnname = oldcolumnname FROM dbo.tablename
ALTER TABLE dbo.tablename DROP COLUMN oldcolumnname
that should do it. unless i have misunderstood your questions?

Create File Group on different drive and move table into it

How can I create a File Group on a different drive with MSSQL 2005 and then move a table into it?
Ex: my database is on H:\Product.mdf and H:\Product.ldf
I want to create a new file group on F:\FileGroup\ and then move my table with a clustered index to this new file group.
This is not a simple task, and depending on the size of your tables may require a chunk of downtime.
First, you have to define the new file group:
ALTER DATABASE MyDatabase
add filegroup NewGroup
Then, create an appropriate file for that file group, for example:
ALTER DATABASE MyDatabase
add file
(
name = NewFile
,filename = 'C:\temp\NewFile.ndf'
,size = 100MB
,maxsize = unlimited
,filegrowth = 100MB
)
to filegroup NewGroup
To move a table onto the file group, you have to create a clustered index for that table on the file group. If you've got a clustered constraint (such as a unique or primary key), you'll have to drop it first. Here's one way to move such a table:
-- Set up sample table
CREATE TABLE MyTable
(
Data varchar(100) not null
constraint PK_MyTable
primary key clustered
)
-- Can't "move" primary key constraint to a new file group
ALTER TABLE MyTable
drop constraint PK_MyTable
-- This will move the data in the table to the new file group
CREATE clustered index Move_MyTable
on MyTable (Data)
on NewGroup
-- Still in the new file group, just no index
DROP INDEX MyTable.Move_MyTable
-- Recreate the primary key, keeping it on the new file group
ALTER TABLE MyTable
add constraint PK_MyTable
primary key clustered (Data)
on NewGroup
It is just a bit fussy, so be sure to test everything on copies of your databases first!