Included columns in index.. performance implications ?

How detrimental is it to create multiple indexes that have included columns
as opposed to creating composite indexes that include that all those columns
?
I want to add the index with included columns but also concerned about
slowness in performance on writes. Either way I want to create the index..
the only difference will be whether I decide to have those included columns
or not..
ThanksIt is not really a performance decision. It depends if those columns will be
used, for example, on the WHERE clause or just on the SELECT clause. If thes
e
columns will be listed only in the SELECT clause then use included columns.
If you are going to use those columns as a search criteria then included
columns would not help.
Regarding performance, include columns are better because they are only
stored at the leaf level of the index.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:

> How detrimental is it to create multiple indexes that have included column
s
> as opposed to creating composite indexes that include that all those colum
ns
> ?
> I want to add the index with included columns but also concerned about
> slowness in performance on writes. Either way I want to create the index.
.
> the only difference will be whether I decide to have those included column
s
> or not..
> Thanks
>

Included columns in index.. performance implications ?

How detrimental is it to create multiple indexes that have included columns
as opposed to creating composite indexes that include that all those columns
?
I want to add the index with included columns but also concerned about
slowness in performance on writes. Either way I want to create the index..
the only difference will be whether I decide to have those included columns
or not..
Thanks
It is not really a performance decision. It depends if those columns will be
used, for example, on the WHERE clause or just on the SELECT clause. If these
columns will be listed only in the SELECT clause then use included columns.
If you are going to use those columns as a search criteria then included
columns would not help.
Regarding performance, include columns are better because they are only
stored at the leaf level of the index.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:

> How detrimental is it to create multiple indexes that have included columns
> as opposed to creating composite indexes that include that all those columns
> ?
> I want to add the index with included columns but also concerned about
> slowness in performance on writes. Either way I want to create the index..
> the only difference will be whether I decide to have those included columns
> or not..
> Thanks
>

Included columns in index.. performance implications ?

How detrimental is it to create multiple indexes that have included columns
as opposed to creating composite indexes that include that all those columns
?
I want to add the index with included columns but also concerned about
slowness in performance on writes. Either way I want to create the index..
the only difference will be whether I decide to have those included columns
or not..
ThanksIt is not really a performance decision. It depends if those columns will be
used, for example, on the WHERE clause or just on the SELECT clause. If these
columns will be listed only in the SELECT clause then use included columns.
If you are going to use those columns as a search criteria then included
columns would not help.
Regarding performance, include columns are better because they are only
stored at the leaf level of the index.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:
> How detrimental is it to create multiple indexes that have included columns
> as opposed to creating composite indexes that include that all those columns
> ?
> I want to add the index with included columns but also concerned about
> slowness in performance on writes. Either way I want to create the index..
> the only difference will be whether I decide to have those included columns
> or not..
> Thanks
>

include .mdf, .ndf, and .ldf files in exclusion list

Hi,
In the past I have always included .mdf, .ndf, and .ldf files in the
exclusion list for
both Antivirus and backup agents.
This message is primarily in regards to an open file backup agent.
I now work at a place that has an open file back agent.
Prior to my arriving the previous dba sucessfully tested a backup to tape
and restore using this agent.
Then DR plan was written to make use of this paradigm.
Fast forward 6 months
New product in production, many open file errors on .mdf, .ndf, and .ldf
files causing entrire backup streams to be delayed and eventually failing.
Immediately resolved when file extensions are added to exlusion list.
Does my old school thought process (exclude the files) lack a basis in the
new landscape involving SQL 2K5 and new backup agents?
Can anyone point to a MS document that recommends this as best practise?
I have seen Microsoft KB article 309422 regarding anit virus files.
Any input apprciated.
Hi Joe
I would exclude the files from any filter agent as this can lead to
performance problems, therefore it would be true regardless of SQL server
version. You will need to look at the SLA and find out what level of recovery
is required and how that could be met.
John
"Joe" wrote:

> Hi,
> In the past I have always included .mdf, .ndf, and .ldf files in the
> exclusion list for
> both Antivirus and backup agents.
> This message is primarily in regards to an open file backup agent.
> I now work at a place that has an open file back agent.
> Prior to my arriving the previous dba sucessfully tested a backup to tape
> and restore using this agent.
> Then DR plan was written to make use of this paradigm.
> Fast forward 6 months
> New product in production, many open file errors on .mdf, .ndf, and .ldf
> files causing entrire backup streams to be delayed and eventually failing.
> Immediately resolved when file extensions are added to exlusion list.
> Does my old school thought process (exclude the files) lack a basis in the
> new landscape involving SQL 2K5 and new backup agents?
> Can anyone point to a MS document that recommends this as best practise?
> I have seen Microsoft KB article 309422 regarding anit virus files.
> Any input apprciated.

include .mdf, .ndf, and .ldf files in exclusion list

Hi,
In the past I have always included .mdf, .ndf, and .ldf files in the
exclusion list for
both Antivirus and backup agents.
This message is primarily in regards to an open file backup agent.
I now work at a place that has an open file back agent.
Prior to my arriving the previous dba sucessfully tested a backup to tape
and restore using this agent.
Then DR plan was written to make use of this paradigm.
Fast forward 6 months
New product in production, many open file errors on .mdf, .ndf, and .ldf
files causing entrire backup streams to be delayed and eventually failing.
Immediately resolved when file extensions are added to exlusion list.
Does my old school thought process (exclude the files) lack a basis in the
new landscape involving SQL 2K5 and new backup agents?
Can anyone point to a MS document that recommends this as best practise?
I have seen Microsoft KB article 309422 regarding anit virus files.
Any input apprciated.Hi Joe
I would exclude the files from any filter agent as this can lead to
performance problems, therefore it would be true regardless of SQL server
version. You will need to look at the SLA and find out what level of recover
y
is required and how that could be met.
John
"Joe" wrote:

> Hi,
> In the past I have always included .mdf, .ndf, and .ldf files in the
> exclusion list for
> both Antivirus and backup agents.
> This message is primarily in regards to an open file backup agent.
> I now work at a place that has an open file back agent.
> Prior to my arriving the previous dba sucessfully tested a backup to tape
> and restore using this agent.
> Then DR plan was written to make use of this paradigm.
> Fast forward 6 months
> New product in production, many open file errors on .mdf, .ndf, and .ldf
> files causing entrire backup streams to be delayed and eventually failing.
> Immediately resolved when file extensions are added to exlusion list.
> Does my old school thought process (exclude the files) lack a basis in the
> new landscape involving SQL 2K5 and new backup agents?
> Can anyone point to a MS document that recommends this as best practise?
> I have seen Microsoft KB article 309422 regarding anit virus files.
> Any input apprciated.