Skip to main content

Brief Theoretical Knowledge about Table Partitioning

1. Partitioning is fully depended on Filegroups.

2. Start table partitioning as early as possible. So that huge data movement can be avoided later.

3. A file would be grouped to one and only Filegroups. Actually Filegroups improves database maintenance, performance and Online restore.

4. For your information, default Filegroup is always “primary filegroup“. If at all you don’t believe me! Create a dummy table something like this,

Create Table Test
(
sno int
)
Go

Now in your SQL Mgmt Studio, right click on that table and check the properties yourself.

5. All “System Objects” have to belong to PRIMARY Filegroup.

6. It’s recommended, to have all “User Objects” created in another Filegroup.

7. In SQL Server 2000, any user object can’t belong to more than one Filegroup. But it’s possible now in SQL Server 2005. That is, a table data can be partitioned and stored into multiple Filegroups.

8. If you have two large tables, put them into different Filegroups. Filegroups are recommended being on two different “Physical” drives.

Physical drive (hard disk) – has a spindle which has “reads per second”, “writes per second” which in turn determines the performance. While joining these 2 tables, parallel retrieval happens based on their spindle speed (since it involves two different physical drives). So there would be a boost in performance.

9. Filegroups are database specific. That is, if you create a “Filegroup1” for Database1 it won’t be available for any other databases.

10. Tables and Indexes can reside on different Filegroups.

11. Partition can be created based on the “Partition key”. Typically it would be based on the
“Date” field.

12. People querying the table need not bother about fetching records from different partition. Because SQL Engine takes care of it internally.

13. You can create separate partition for storing historic data.

14. Maintenance plan needs to be created based on the Filegroup.

15. By the way, we can set Filegroup as Read-only also. Lookup tables or tables which don’t go to change at all needs to be placed in Read-only groups. So it’s enough if we backup this Filegroup once.

16. In SQL Server 2000, we need to “Restore” all Filegroups then only we can make the database online. In SQL Server 2005, once the Primary Filegroup is up we can bring the database online. So functionality wise grouping should be done in a Filegroup.

In the next post I would talk about the steps involved in creating a partition and the different types of operations in a partition.

Technorati tags: ,

Comments

Anonymous said…
4. For your information, default Filegroup is always “primary filegroup“. If at all you don’t believe me! Create a dummy table something like this,

Create Table Test
(
sno int
)
Go

Alter database xyz modify filegroup abc default;

will change the default filegroup for new object creation.
Vadivel said…
Thats true. My argument holds good as long as the users haven't changed their default filegroup of installation :)

Popular posts from this blog

Registry manipulation from SQL

Registry Manupulation from SQL Server is pretty easy. There are 4 extended stored procedure in SQL Server 2000 for the purpose of manupulating the server registry. They are: 1) xp_regwrite 2) xp_regread 3) xp_regdeletekey 4) xp_regdeletevalue Let us see each one of them in detail! About xp_regwrite This extended stored procedure helps us to create data item in the (server’s) registry and we could also create a new key. Usage: We must specify the root key with the @rootkey parameter and an individual key with the @key parameter. Please note that if the key doesn’t exist (without any warnnig) it would be created in the registry. The @value_name parameter designates the data item and the @type the type of the data item. Valid data item types include REG_SZ and REG_DWORD . The last parameter is the @value parameter, which assigns a value to the data item. Let us now see an example which would add a new key called " TestKey ", and a new data item under it called TestKeyValue :

Screen scraping using XmlHttp and Vbscript ...

I wrote a small program for screen scraping any sites using XmlHttp object and VBScript. I know I haven't done any rocket science :) still I thought of sharing the code with you all. XmlHttp -- E x tensible M arkup L anguage H ypertext T ransfer P rotocol An advantage is that - the XmlHttp object queries the server and retrieve the latest information without reloading the page. Source code: < html > < head > < script language ="vbscript"> Dim objXmlHttp Set objXmlHttp = CreateObject("Msxml2.XMLHttp") Function ScreenScrapping() URL == "UR site URL comes here" objXmlHttp.Open "POST", url, False objXmlHttp.onreadystatechange = getref("HandleStateChange") objXmlHttp.Send End Function Function HandleStateChange() If (ObjXmlHttp.readyState = 4) Then msgbox "Screenscrapping completed .." divShowContent.innerHtml = objXmlHttp.responseText End If End Function </ script > < head > < body > &l

Script table as - ALTER TO is greyed out - SQL SERVER

One of my office colleague recently asked me why we are not able to generate ALTER Table script from SSMS. If we right click on the table and choose "Script Table As"  ALTER To option would be disabled or Greyed out. Is it a bug? No it isn't a bug. ALTER To is there to be used for generating modified script of Stored Procedure, Functions, Views, Triggers etc., and NOT for Tables. For generating ALTER Table script there is an work around. Right click on the table, choose "Modify" and enter into the design mode. Make what ever changes you want to make and WITHOUT saving it right click anywhere on the top half of the window (above Column properties) and choose "Generate Change Script". Please be advised that SQL Server would drop actually create a new table with modifications, move the data from the old table into it and then drop the old table. Sounds simple but assume you have a very large table for which you want to do this! Then it woul