create an Indexes/Keys Property with T-SQL

is there a function that i can use in a store procedure that allow me to create an Indexes/Keys Property
thanxYes. CREATE INDEX.

-PatP|||Yes. CREATE INDEX.

-PatP

excuse me while I climb back on my barstool...um office chair...

LNHockey...seriously though... alittle more background on what you're trying to do...

"create index"....why I outta.....|||Yes ok..excuse me.

i do this
<b>
ALTER TABLE TblSalle ADD [IdTypeTaxe] [int] NOT NULL default(0)<br>
CREATE INDEX PK_TblSalle ON TblSalle (IdTypeTaxe)</b>

and would like to assign is "Selected index value" to IX_IdTypeTaxe that i userly have in a combobox when i use the sql manager

but i want to do it in a store proc..

or how can i modify that value after i add the new column to my table|||Yup...I'm lost..

Huh?|||You know when you go to design mode of the table and go properties of the selected column and select the tab "Indexes/keys". under that you can switch the type "Primary key to Index" ?? !!!

just wondering if we can do the same thing in a Store proc using a function kind of thing

thanx !

Create a Temp Table

If I am going to create a temp table and insert data into it, would I
be better of creating the indexes after I do the insert?
Does it matter?If the amount of rows to be inserted is huge, sure. Better to test it.
AMB
"Bob" wrote:

> If I am going to create a temp table and insert data into it, would I
> be better of creating the indexes after I do the insert?
> Does it matter?
>

Crash with "Failed Assertion"

Hello,
I have a table with 2 indexes.
My C++ program deletes some data from this table and then
does bcp data in. It does it twice in one run.
After I run my program for the first time I get the
correct result. When I run it again, the first bcp is
successful, however there is no data from the second bcp.
If I repeat it again, the result is correct; one more
time - the data from the first bcp only.
If I try to debug it, everything works fine.
If I run it without break points in the program, I
duplicate a problem.
SQL Server log records an error:
Failed Assertion = '(logMode != nonlogged) || (dbt-
>dbt_dbid == TEMPDBID)'
and creates a SQLdump file, which I don't know how to
interprit.
If I remove indexes from the table, everything works fine.
Does anyone understand what's going on?
I would appriciate any help.
Thanks.Are your indexes unique indexes? Chances are thats why it's failing the
second time, if you're using the same data in you're BCP load.
-Morgan
"Tanya Bardakh" <tbardakh@.dysanalytics.com> wrote in message
news:0cf001c39d5d$a3068a20$a401280a@.phx.gbl...
> Hello,
>
> I have a table with 2 indexes.
> My C++ program deletes some data from this table and then
> does bcp data in. It does it twice in one run.
> After I run my program for the first time I get the
> correct result. When I run it again, the first bcp is
> successful, however there is no data from the second bcp.
> If I repeat it again, the result is correct; one more
> time - the data from the first bcp only.
> If I try to debug it, everything works fine.
> If I run it without break points in the program, I
> duplicate a problem.
> SQL Server log records an error:
> Failed Assertion = '(logMode != nonlogged) || (dbt-
> >dbt_dbid == TEMPDBID)'
> and creates a SQLdump file, which I don't know how to
> interprit.
> If I remove indexes from the table, everything works fine.
> Does anyone understand what's going on?
> I would appriciate any help.
> Thanks.
>
>|||Thank you for the reply.
My indexes are not unique, nor cluster.
Tanya.
>--Original Message--
>Are your indexes unique indexes? Chances are thats why
it's failing the
>second time, if you're using the same data in you're BCP
load.
>-Morgan
>"Tanya Bardakh" <tbardakh@.dysanalytics.com> wrote in
message
>news:0cf001c39d5d$a3068a20$a401280a@.phx.gbl...
>> Hello,
>>
>> I have a table with 2 indexes.
>> My C++ program deletes some data from this table and
then
>> does bcp data in. It does it twice in one run.
>> After I run my program for the first time I get the
>> correct result. When I run it again, the first bcp is
>> successful, however there is no data from the second
bcp.
>> If I repeat it again, the result is correct; one more
>> time - the data from the first bcp only.
>> If I try to debug it, everything works fine.
>> If I run it without break points in the program, I
>> duplicate a problem.
>> SQL Server log records an error:
>> Failed Assertion = '(logMode != nonlogged) || (dbt-
>> >dbt_dbid == TEMPDBID)'
>> and creates a SQLdump file, which I don't know how to
>> interprit.
>> If I remove indexes from the table, everything works
fine.
>> Does anyone understand what's going on?
>> I would appriciate any help.
>> Thanks.
>>
>
>.
>|||Any replication on the tables involved?
How about triggers?
If the answer to the above is "no", the only thing I can think of is that
you're running out of space in the logfile and you have configured for
"Simple" recovery model. It would work in "debug" because SQLServer would
have time to remove the previous checkpoint...
Bruce
"Tanya Bardakh" <anonymous@.discussions.microsoft.com> wrote in message
news:0de201c39d64$5d354b10$a401280a@.phx.gbl...
> Thank you for the reply.
> My indexes are not unique, nor cluster.
> Tanya.
>
> >--Original Message--
> >Are your indexes unique indexes? Chances are thats why
> it's failing the
> >second time, if you're using the same data in you're BCP
> load.
> >
> >-Morgan
> >
> >"Tanya Bardakh" <tbardakh@.dysanalytics.com> wrote in
> message
> >news:0cf001c39d5d$a3068a20$a401280a@.phx.gbl...
> >> Hello,
> >>
> >>
> >> I have a table with 2 indexes.
> >> My C++ program deletes some data from this table and
> then
> >> does bcp data in. It does it twice in one run.
> >>
> >> After I run my program for the first time I get the
> >> correct result. When I run it again, the first bcp is
> >> successful, however there is no data from the second
> bcp.
> >> If I repeat it again, the result is correct; one more
> >> time - the data from the first bcp only.
> >>
> >> If I try to debug it, everything works fine.
> >>
> >> If I run it without break points in the program, I
> >> duplicate a problem.
> >>
> >> SQL Server log records an error:
> >> Failed Assertion = '(logMode != nonlogged) || (dbt-
> >> >dbt_dbid == TEMPDBID)'
> >> and creates a SQLdump file, which I don't know how to
> >> interprit.
> >>
> >> If I remove indexes from the table, everything works
> fine.
> >>
> >> Does anyone understand what's going on?
> >>
> >> I would appriciate any help.
> >> Thanks.
> >>
> >>
> >>
> >
> >
> >.
> >|||Thank you, Bruce
I don't have any triggers & replications.
Space should not be an issue, since I have plenty of it
(30 GB). Actually I am reloading same data (about 200
rows) over and over again. The only thing is it's
successful the first time and crashes SQL server on the
subsequent run.
>--Original Message--
>Any replication on the tables involved?
>How about triggers?
>If the answer to the above is "no", the only thing I can
think of is that
>you're running out of space in the logfile and you have
configured for
>"Simple" recovery model. It would work in "debug"
because SQLServer would
>have time to remove the previous checkpoint...
>Bruce
>"Tanya Bardakh" <anonymous@.discussions.microsoft.com>
wrote in message
>news:0de201c39d64$5d354b10$a401280a@.phx.gbl...
>> Thank you for the reply.
>> My indexes are not unique, nor cluster.
>> Tanya.
>>
>> >--Original Message--
>> >Are your indexes unique indexes? Chances are thats why
>> it's failing the
>> >second time, if you're using the same data in you're
BCP
>> load.
>> >
>> >-Morgan
>> >
>> >"Tanya Bardakh" <tbardakh@.dysanalytics.com> wrote in
>> message
>> >news:0cf001c39d5d$a3068a20$a401280a@.phx.gbl...
>> >> Hello,
>> >>
>> >>
>> >> I have a table with 2 indexes.
>> >> My C++ program deletes some data from this table and
>> then
>> >> does bcp data in. It does it twice in one run.
>> >>
>> >> After I run my program for the first time I get the
>> >> correct result. When I run it again, the first bcp is
>> >> successful, however there is no data from the second
>> bcp.
>> >> If I repeat it again, the result is correct; one more
>> >> time - the data from the first bcp only.
>> >>
>> >> If I try to debug it, everything works fine.
>> >>
>> >> If I run it without break points in the program, I
>> >> duplicate a problem.
>> >>
>> >> SQL Server log records an error:
>> >> Failed Assertion = '(logMode != nonlogged) || (dbt-
>> >> >dbt_dbid == TEMPDBID)'
>> >> and creates a SQLdump file, which I don't know how to
>> >> interprit.
>> >>
>> >> If I remove indexes from the table, everything works
>> fine.
>> >>
>> >> Does anyone understand what's going on?
>> >>
>> >> I would appriciate any help.
>> >> Thanks.
>> >>
>> >>
>> >>
>> >
>> >
>> >.
>> >
>
>.
>|||You should contact Product Support (http://support.microsoft.com) who will
be able to help you figure this out.
Regards,
Paul.
--
Paul Randal
DBCC Technical Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"bcarson@.asgoth.com" <anonymous@.discussions.microsoft.com> wrote in message
news:027e01c39d82$9d9c2070$a301280a@.phx.gbl...
> Thank you, Bruce
> I don't have any triggers & replications.
> Space should not be an issue, since I have plenty of it
> (30 GB). Actually I am reloading same data (about 200
> rows) over and over again. The only thing is it's
> successful the first time and crashes SQL server on the
> subsequent run.
>
> >--Original Message--
> >Any replication on the tables involved?
> >How about triggers?
> >
> >If the answer to the above is "no", the only thing I can
> think of is that
> >you're running out of space in the logfile and you have
> configured for
> >"Simple" recovery model. It would work in "debug"
> because SQLServer would
> >have time to remove the previous checkpoint...
> >
> >Bruce
> >
> >"Tanya Bardakh" <anonymous@.discussions.microsoft.com>
> wrote in message
> >news:0de201c39d64$5d354b10$a401280a@.phx.gbl...
> >> Thank you for the reply.
> >>
> >> My indexes are not unique, nor cluster.
> >>
> >> Tanya.
> >>
> >>
> >> >--Original Message--
> >> >Are your indexes unique indexes? Chances are thats why
> >> it's failing the
> >> >second time, if you're using the same data in you're
> BCP
> >> load.
> >> >
> >> >-Morgan
> >> >
> >> >"Tanya Bardakh" <tbardakh@.dysanalytics.com> wrote in
> >> message
> >> >news:0cf001c39d5d$a3068a20$a401280a@.phx.gbl...
> >> >> Hello,
> >> >>
> >> >>
> >> >> I have a table with 2 indexes.
> >> >> My C++ program deletes some data from this table and
> >> then
> >> >> does bcp data in. It does it twice in one run.
> >> >>
> >> >> After I run my program for the first time I get the
> >> >> correct result. When I run it again, the first bcp is
> >> >> successful, however there is no data from the second
> >> bcp.
> >> >> If I repeat it again, the result is correct; one more
> >> >> time - the data from the first bcp only.
> >> >>
> >> >> If I try to debug it, everything works fine.
> >> >>
> >> >> If I run it without break points in the program, I
> >> >> duplicate a problem.
> >> >>
> >> >> SQL Server log records an error:
> >> >> Failed Assertion = '(logMode != nonlogged) || (dbt-
> >> >> >dbt_dbid == TEMPDBID)'
> >> >> and creates a SQLdump file, which I don't know how to
> >> >> interprit.
> >> >>
> >> >> If I remove indexes from the table, everything works
> >> fine.
> >> >>
> >> >> Does anyone understand what's going on?
> >> >>
> >> >> I would appriciate any help.
> >> >> Thanks.
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >.
> >> >
> >
> >
> >.
> >

cpu going high (100%) after Index is created

Hi,
Any idea why CPU is going to 100% utilization as soon as i created index
(non clustered) on a table which has indexes already on the table.
before creating index the CPU is about 10 to 20% busy, after creating index
it is going to 100% consistently for about 10 minutes then i dropped index
cpu usage came down to normal
Thanks,
SUBBU.creating index is a resource intensive process, that is one of the
reason people normally find a off peak window for reindexing.
Resources varies depends on how many rows you have of the table and how
many columns you include in the non-clustered index and what are they
(data type).
If you can provide clustered index columns (if any), non-clustered
index columns (the one you intended to put), we can find out more.
Mel|||Hi
I understand creating CPU is resource intensive. CPU is going high after
index is created not while being created.
As of now the table has 98000 rows, aprox 800 pages, 1 clustered composite,
6 non clustered composite.
Data is very static in nature
Thanks,
Subbu.
"MSLam" <MelodySLam@.googlemail.com> wrote in message
news:1144960243.264788.102540@.z34g2000cwc.googlegroups.com...
> creating index is a resource intensive process, that is one of the
> reason people normally find a off peak window for reindexing.
> Resources varies depends on how many rows you have of the table and how
> many columns you include in the non-clustered index and what are they
> (data type).
> If you can provide clustered index columns (if any), non-clustered
> index columns (the one you intended to put), we can find out more.
> Mel
>|||You might just have gotten a bad plan. I would try it again.
--
Andrew J. Kelly SQL MVP
"subbu" <subbaiahd@.hotmail.com> wrote in message
news:%235Pf63zXGHA.3516@.TK2MSFTNGP03.phx.gbl...
> Hi
> I understand creating CPU is resource intensive. CPU is going high after
> index is created not while being created.
> As of now the table has 98000 rows, aprox 800 pages, 1 clustered
> composite,
> 6 non clustered composite.
> Data is very static in nature
> Thanks,
> Subbu.
>
> "MSLam" <MelodySLam@.googlemail.com> wrote in message
> news:1144960243.264788.102540@.z34g2000cwc.googlegroups.com...
>> creating index is a resource intensive process, that is one of the
>> reason people normally find a off peak window for reindexing.
>> Resources varies depends on how many rows you have of the table and how
>> many columns you include in the non-clustered index and what are they
>> (data type).
>> If you can provide clustered index columns (if any), non-clustered
>> index columns (the one you intended to put), we can find out more.
>> Mel
>|||Sorry misunderstood your question in the first place.
One thing to bear in mind that putting index is NOT costless. In fact,
having more than enough indexes can cause problem, particularly if you
enviornment is OLTP. It will help for SELECT but not
UPDATE/INSERT/DELETE (as the index will need to be updated at the same
time).
My rule is always have a one good clustered index and 1-3 non-clustered
indexes should do the job.
Mel|||(BI = Before Index Created
AI = After Index created)
The query for which i have created index is executing faster AI. the query
which was going for index scan (BI) now going for index seek (AI), and
total execution time came down from 9 sec to 1 sec. But CPU is going to
100%, I am guessing does the new index made all other queries to run slow. I
dont worry about INSERT/DELETE/UPDATE, I need to tune SELECT stmts only
(the data is very static). Is SQL Server not intelligent to ignore indexes
that are not useful in plan preparation. If i create a new index it looks
like other queries which joins this table are going to wrong execution
plans. Please help.
Thanks,
Subbu
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:OltKJu1XGHA.4652@.TK2MSFTNGP04.phx.gbl...
> You might just have gotten a bad plan. I would try it again.
> --
> Andrew J. Kelly SQL MVP
>
> "subbu" <subbaiahd@.hotmail.com> wrote in message
> news:%235Pf63zXGHA.3516@.TK2MSFTNGP03.phx.gbl...
> > Hi
> >
> > I understand creating CPU is resource intensive. CPU is going high after
> > index is created not while being created.
> >
> > As of now the table has 98000 rows, aprox 800 pages, 1 clustered
> > composite,
> > 6 non clustered composite.
> >
> > Data is very static in nature
> >
> > Thanks,
> > Subbu.
> >
> >
> > "MSLam" <MelodySLam@.googlemail.com> wrote in message
> > news:1144960243.264788.102540@.z34g2000cwc.googlegroups.com...
> >> creating index is a resource intensive process, that is one of the
> >> reason people normally find a off peak window for reindexing.
> >>
> >> Resources varies depends on how many rows you have of the table and how
> >> many columns you include in the non-clustered index and what are they
> >> (data type).
> >>
> >> If you can provide clustered index columns (if any), non-clustered
> >> index columns (the one you intended to put), we can find out more.
> >>
> >> Mel
> >>
> >
> >
>|||How many CPU's do you have? It's possible that parallelism is being used
suboptimally. I'd use the Profiler to find which queries are being
affected. For those, you may want to use OPTION (MAXDOP 1).
--
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"subbu" <subbaiahd@.hotmail.com> wrote in message
news:uLyApr8XGHA.4920@.TK2MSFTNGP02.phx.gbl...
(BI = Before Index Created
AI = After Index created)
The query for which i have created index is executing faster AI. the query
which was going for index scan (BI) now going for index seek (AI), and
total execution time came down from 9 sec to 1 sec. But CPU is going to
100%, I am guessing does the new index made all other queries to run slow. I
dont worry about INSERT/DELETE/UPDATE, I need to tune SELECT stmts only
(the data is very static). Is SQL Server not intelligent to ignore indexes
that are not useful in plan preparation. If i create a new index it looks
like other queries which joins this table are going to wrong execution
plans. Please help.
Thanks,
Subbu
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:OltKJu1XGHA.4652@.TK2MSFTNGP04.phx.gbl...
> You might just have gotten a bad plan. I would try it again.
> --
> Andrew J. Kelly SQL MVP
>
> "subbu" <subbaiahd@.hotmail.com> wrote in message
> news:%235Pf63zXGHA.3516@.TK2MSFTNGP03.phx.gbl...
> > Hi
> >
> > I understand creating CPU is resource intensive. CPU is going high after
> > index is created not while being created.
> >
> > As of now the table has 98000 rows, aprox 800 pages, 1 clustered
> > composite,
> > 6 non clustered composite.
> >
> > Data is very static in nature
> >
> > Thanks,
> > Subbu.
> >
> >
> > "MSLam" <MelodySLam@.googlemail.com> wrote in message
> > news:1144960243.264788.102540@.z34g2000cwc.googlegroups.com...
> >> creating index is a resource intensive process, that is one of the
> >> reason people normally find a off peak window for reindexing.
> >>
> >> Resources varies depends on how many rows you have of the table and how
> >> many columns you include in the non-clustered index and what are they
> >> (data type).
> >>
> >> If you can provide clustered index columns (if any), non-clustered
> >> index columns (the one you intended to put), we can find out more.
> >>
> >> Mel
> >>
> >
> >
>|||Thanks for the idea, i have one cpu.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23H$8I$8XGHA.128@.TK2MSFTNGP05.phx.gbl...
> How many CPU's do you have? It's possible that parallelism is being used
> suboptimally. I'd use the Profiler to find which queries are being
> affected. For those, you may want to use OPTION (MAXDOP 1).
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> .
> "subbu" <subbaiahd@.hotmail.com> wrote in message
> news:uLyApr8XGHA.4920@.TK2MSFTNGP02.phx.gbl...
> (BI = Before Index Created
> AI = After Index created)
>
> The query for which i have created index is executing faster AI. the query
> which was going for index scan (BI) now going for index seek (AI), and
> total execution time came down from 9 sec to 1 sec. But CPU is going to
> 100%, I am guessing does the new index made all other queries to run slow.
I
> dont worry about INSERT/DELETE/UPDATE, I need to tune SELECT stmts only
> (the data is very static). Is SQL Server not intelligent to ignore indexes
> that are not useful in plan preparation. If i create a new index it looks
> like other queries which joins this table are going to wrong execution
> plans. Please help.
> Thanks,
> Subbu
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:OltKJu1XGHA.4652@.TK2MSFTNGP04.phx.gbl...
> > You might just have gotten a bad plan. I would try it again.
> >
> > --
> > Andrew J. Kelly SQL MVP
> >
> >
> > "subbu" <subbaiahd@.hotmail.com> wrote in message
> > news:%235Pf63zXGHA.3516@.TK2MSFTNGP03.phx.gbl...
> > > Hi
> > >
> > > I understand creating CPU is resource intensive. CPU is going high
after
> > > index is created not while being created.
> > >
> > > As of now the table has 98000 rows, aprox 800 pages, 1 clustered
> > > composite,
> > > 6 non clustered composite.
> > >
> > > Data is very static in nature
> > >
> > > Thanks,
> > > Subbu.
> > >
> > >
> > > "MSLam" <MelodySLam@.googlemail.com> wrote in message
> > > news:1144960243.264788.102540@.z34g2000cwc.googlegroups.com...
> > >> creating index is a resource intensive process, that is one of the
> > >> reason people normally find a off peak window for reindexing.
> > >>
> > >> Resources varies depends on how many rows you have of the table and
how
> > >> many columns you include in the non-clustered index and what are they
> > >> (data type).
> > >>
> > >> If you can provide clustered index columns (if any), non-clustered
> > >> index columns (the one you intended to put), we can find out more.
> > >>
> > >> Mel
> > >>
> > >
> > >
> >
> >
>|||Well, it's not parallelism, then. I'd still use the profiler to figure out
where the bones are buried.
--
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"subbu" <subbaiahd@.hotmail.com> wrote in message
news:eoh%23Ks9XGHA.4248@.TK2MSFTNGP05.phx.gbl...
Thanks for the idea, i have one cpu.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23H$8I$8XGHA.128@.TK2MSFTNGP05.phx.gbl...
> How many CPU's do you have? It's possible that parallelism is being used
> suboptimally. I'd use the Profiler to find which queries are being
> affected. For those, you may want to use OPTION (MAXDOP 1).
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> .
> "subbu" <subbaiahd@.hotmail.com> wrote in message
> news:uLyApr8XGHA.4920@.TK2MSFTNGP02.phx.gbl...
> (BI = Before Index Created
> AI = After Index created)
>
> The query for which i have created index is executing faster AI. the query
> which was going for index scan (BI) now going for index seek (AI), and
> total execution time came down from 9 sec to 1 sec. But CPU is going to
> 100%, I am guessing does the new index made all other queries to run slow.
I
> dont worry about INSERT/DELETE/UPDATE, I need to tune SELECT stmts only
> (the data is very static). Is SQL Server not intelligent to ignore indexes
> that are not useful in plan preparation. If i create a new index it looks
> like other queries which joins this table are going to wrong execution
> plans. Please help.
> Thanks,
> Subbu
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:OltKJu1XGHA.4652@.TK2MSFTNGP04.phx.gbl...
> > You might just have gotten a bad plan. I would try it again.
> >
> > --
> > Andrew J. Kelly SQL MVP
> >
> >
> > "subbu" <subbaiahd@.hotmail.com> wrote in message
> > news:%235Pf63zXGHA.3516@.TK2MSFTNGP03.phx.gbl...
> > > Hi
> > >
> > > I understand creating CPU is resource intensive. CPU is going high
after
> > > index is created not while being created.
> > >
> > > As of now the table has 98000 rows, aprox 800 pages, 1 clustered
> > > composite,
> > > 6 non clustered composite.
> > >
> > > Data is very static in nature
> > >
> > > Thanks,
> > > Subbu.
> > >
> > >
> > > "MSLam" <MelodySLam@.googlemail.com> wrote in message
> > > news:1144960243.264788.102540@.z34g2000cwc.googlegroups.com...
> > >> creating index is a resource intensive process, that is one of the
> > >> reason people normally find a off peak window for reindexing.
> > >>
> > >> Resources varies depends on how many rows you have of the table and
how
> > >> many columns you include in the non-clustered index and what are they
> > >> (data type).
> > >>
> > >> If you can provide clustered index columns (if any), non-clustered
> > >> index columns (the one you intended to put), we can find out more.
> > >>
> > >> Mel
> > >>
> > >
> > >
> >
> >
>|||If you query originally took 9 seconds and now takes 1 then you must be
returning a lot of rows. The CPU going to 100% is probably just a sign that
it is now able to process more efficiently and thus faster. If no one lese
is on the server and you issue the query and the CPU spikes to 100% for 1
second and then drops to 0 everything is OK.
--
Andrew J. Kelly SQL MVP
"subbu" <subbaiahd@.hotmail.com> wrote in message
news:uLyApr8XGHA.4920@.TK2MSFTNGP02.phx.gbl...
> (BI = Before Index Created
> AI = After Index created)
>
> The query for which i have created index is executing faster AI. the query
> which was going for index scan (BI) now going for index seek (AI), and
> total execution time came down from 9 sec to 1 sec. But CPU is going to
> 100%, I am guessing does the new index made all other queries to run slow.
> I
> dont worry about INSERT/DELETE/UPDATE, I need to tune SELECT stmts only
> (the data is very static). Is SQL Server not intelligent to ignore indexes
> that are not useful in plan preparation. If i create a new index it looks
> like other queries which joins this table are going to wrong execution
> plans. Please help.
> Thanks,
> Subbu
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:OltKJu1XGHA.4652@.TK2MSFTNGP04.phx.gbl...
>> You might just have gotten a bad plan. I would try it again.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "subbu" <subbaiahd@.hotmail.com> wrote in message
>> news:%235Pf63zXGHA.3516@.TK2MSFTNGP03.phx.gbl...
>> > Hi
>> >
>> > I understand creating CPU is resource intensive. CPU is going high
>> > after
>> > index is created not while being created.
>> >
>> > As of now the table has 98000 rows, aprox 800 pages, 1 clustered
>> > composite,
>> > 6 non clustered composite.
>> >
>> > Data is very static in nature
>> >
>> > Thanks,
>> > Subbu.
>> >
>> >
>> > "MSLam" <MelodySLam@.googlemail.com> wrote in message
>> > news:1144960243.264788.102540@.z34g2000cwc.googlegroups.com...
>> >> creating index is a resource intensive process, that is one of the
>> >> reason people normally find a off peak window for reindexing.
>> >>
>> >> Resources varies depends on how many rows you have of the table and
>> >> how
>> >> many columns you include in the non-clustered index and what are they
>> >> (data type).
>> >>
>> >> If you can provide clustered index columns (if any), non-clustered
>> >> index columns (the one you intended to put), we can find out more.
>> >>
>> >> Mel
>> >>
>> >
>> >
>>
>|||Sorry for responding late.
Query is returning only few rows around 25. After query executed even then
cpu is not coming down, query executed in one second cpu is 100% for almost
10 minutes then i dropped new indexes created , and immeadiately cpu came
down to normal (20% ).
Thanks,
Subbu.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eJF9hdAYGHA.4060@.TK2MSFTNGP02.phx.gbl...
> If you query originally took 9 seconds and now takes 1 then you must be
> returning a lot of rows. The CPU going to 100% is probably just a sign
that
> it is now able to process more efficiently and thus faster. If no one lese
> is on the server and you issue the query and the CPU spikes to 100% for 1
> second and then drops to 0 everything is OK.
> --
> Andrew J. Kelly SQL MVP
>
> "subbu" <subbaiahd@.hotmail.com> wrote in message
> news:uLyApr8XGHA.4920@.TK2MSFTNGP02.phx.gbl...
> >
> > (BI = Before Index Created
> > AI = After Index created)
> >
> >
> > The query for which i have created index is executing faster AI. the
query
> > which was going for index scan (BI) now going for index seek (AI), and
> > total execution time came down from 9 sec to 1 sec. But CPU is going to
> > 100%, I am guessing does the new index made all other queries to run
slow.
> > I
> > dont worry about INSERT/DELETE/UPDATE, I need to tune SELECT stmts only
> > (the data is very static). Is SQL Server not intelligent to ignore
indexes
> > that are not useful in plan preparation. If i create a new index it
looks
> > like other queries which joins this table are going to wrong execution
> > plans. Please help.
> >
> > Thanks,
> > Subbu
> >
> > "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> > news:OltKJu1XGHA.4652@.TK2MSFTNGP04.phx.gbl...
> >> You might just have gotten a bad plan. I would try it again.
> >>
> >> --
> >> Andrew J. Kelly SQL MVP
> >>
> >>
> >> "subbu" <subbaiahd@.hotmail.com> wrote in message
> >> news:%235Pf63zXGHA.3516@.TK2MSFTNGP03.phx.gbl...
> >> > Hi
> >> >
> >> > I understand creating CPU is resource intensive. CPU is going high
> >> > after
> >> > index is created not while being created.
> >> >
> >> > As of now the table has 98000 rows, aprox 800 pages, 1 clustered
> >> > composite,
> >> > 6 non clustered composite.
> >> >
> >> > Data is very static in nature
> >> >
> >> > Thanks,
> >> > Subbu.
> >> >
> >> >
> >> > "MSLam" <MelodySLam@.googlemail.com> wrote in message
> >> > news:1144960243.264788.102540@.z34g2000cwc.googlegroups.com...
> >> >> creating index is a resource intensive process, that is one of the
> >> >> reason people normally find a off peak window for reindexing.
> >> >>
> >> >> Resources varies depends on how many rows you have of the table and
> >> >> how
> >> >> many columns you include in the non-clustered index and what are
they
> >> >> (data type).
> >> >>
> >> >> If you can provide clustered index columns (if any), non-clustered
> >> >> index columns (the one you intended to put), we can find out more.
> >> >>
> >> >> Mel
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>|||Again, use the profiler to determine the ling-running queries, as well as
those that take a lot of CPU.
--
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"subbu" <subbaiahd@.hotmail.com> wrote in message
news:OBoqVgiYGHA.3328@.TK2MSFTNGP02.phx.gbl...
Sorry for responding late.
Query is returning only few rows around 25. After query executed even then
cpu is not coming down, query executed in one second cpu is 100% for almost
10 minutes then i dropped new indexes created , and immeadiately cpu came
down to normal (20% ).
Thanks,
Subbu.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eJF9hdAYGHA.4060@.TK2MSFTNGP02.phx.gbl...
> If you query originally took 9 seconds and now takes 1 then you must be
> returning a lot of rows. The CPU going to 100% is probably just a sign
that
> it is now able to process more efficiently and thus faster. If no one lese
> is on the server and you issue the query and the CPU spikes to 100% for 1
> second and then drops to 0 everything is OK.
> --
> Andrew J. Kelly SQL MVP
>
> "subbu" <subbaiahd@.hotmail.com> wrote in message
> news:uLyApr8XGHA.4920@.TK2MSFTNGP02.phx.gbl...
> >
> > (BI = Before Index Created
> > AI = After Index created)
> >
> >
> > The query for which i have created index is executing faster AI. the
query
> > which was going for index scan (BI) now going for index seek (AI), and
> > total execution time came down from 9 sec to 1 sec. But CPU is going to
> > 100%, I am guessing does the new index made all other queries to run
slow.
> > I
> > dont worry about INSERT/DELETE/UPDATE, I need to tune SELECT stmts only
> > (the data is very static). Is SQL Server not intelligent to ignore
indexes
> > that are not useful in plan preparation. If i create a new index it
looks
> > like other queries which joins this table are going to wrong execution
> > plans. Please help.
> >
> > Thanks,
> > Subbu
> >
> > "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> > news:OltKJu1XGHA.4652@.TK2MSFTNGP04.phx.gbl...
> >> You might just have gotten a bad plan. I would try it again.
> >>
> >> --
> >> Andrew J. Kelly SQL MVP
> >>
> >>
> >> "subbu" <subbaiahd@.hotmail.com> wrote in message
> >> news:%235Pf63zXGHA.3516@.TK2MSFTNGP03.phx.gbl...
> >> > Hi
> >> >
> >> > I understand creating CPU is resource intensive. CPU is going high
> >> > after
> >> > index is created not while being created.
> >> >
> >> > As of now the table has 98000 rows, aprox 800 pages, 1 clustered
> >> > composite,
> >> > 6 non clustered composite.
> >> >
> >> > Data is very static in nature
> >> >
> >> > Thanks,
> >> > Subbu.
> >> >
> >> >
> >> > "MSLam" <MelodySLam@.googlemail.com> wrote in message
> >> > news:1144960243.264788.102540@.z34g2000cwc.googlegroups.com...
> >> >> creating index is a resource intensive process, that is one of the
> >> >> reason people normally find a off peak window for reindexing.
> >> >>
> >> >> Resources varies depends on how many rows you have of the table and
> >> >> how
> >> >> many columns you include in the non-clustered index and what are
they
> >> >> (data type).
> >> >>
> >> >> If you can provide clustered index columns (if any), non-clustered
> >> >> index columns (the one you intended to put), we can find out more.
> >> >>
> >> >> Mel
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>

cpu going high (100%) after Index is created

Hi,
Any idea why CPU is going to 100% utilization as soon as i created index
(non clustered) on a table which has indexes already on the table.
before creating index the CPU is about 10 to 20% busy, after creating index
it is going to 100% consistently for about 10 minutes then i dropped index
cpu usage came down to normal
Thanks,
SUBBU.creating index is a resource intensive process, that is one of the
reason people normally find a off peak window for reindexing.
Resources varies depends on how many rows you have of the table and how
many columns you include in the non-clustered index and what are they
(data type).
If you can provide clustered index columns (if any), non-clustered
index columns (the one you intended to put), we can find out more.
Mel|||Hi
I understand creating CPU is resource intensive. CPU is going high after
index is created not while being created.
As of now the table has 98000 rows, aprox 800 pages, 1 clustered composite,
6 non clustered composite.
Data is very static in nature
Thanks,
Subbu.
"MSLam" <MelodySLam@.googlemail.com> wrote in message
news:1144960243.264788.102540@.z34g2000cwc.googlegroups.com...
> creating index is a resource intensive process, that is one of the
> reason people normally find a off peak window for reindexing.
> Resources varies depends on how many rows you have of the table and how
> many columns you include in the non-clustered index and what are they
> (data type).
> If you can provide clustered index columns (if any), non-clustered
> index columns (the one you intended to put), we can find out more.
> Mel
>|||You might just have gotten a bad plan. I would try it again.
Andrew J. Kelly SQL MVP
"subbu" <subbaiahd@.hotmail.com> wrote in message
news:%235Pf63zXGHA.3516@.TK2MSFTNGP03.phx.gbl...
> Hi
> I understand creating CPU is resource intensive. CPU is going high after
> index is created not while being created.
> As of now the table has 98000 rows, aprox 800 pages, 1 clustered
> composite,
> 6 non clustered composite.
> Data is very static in nature
> Thanks,
> Subbu.
>
> "MSLam" <MelodySLam@.googlemail.com> wrote in message
> news:1144960243.264788.102540@.z34g2000cwc.googlegroups.com...
>|||Sorry misunderstood your question in the first place.
One thing to bear in mind that putting index is NOT costless. In fact,
having more than enough indexes can cause problem, particularly if you
enviornment is OLTP. It will help for SELECT but not
UPDATE/INSERT/DELETE (as the index will need to be updated at the same
time).
My rule is always have a one good clustered index and 1-3 non-clustered
indexes should do the job.
Mel|||(BI = Before Index Created
AI = After Index created)
The query for which i have created index is executing faster AI. the query
which was going for index scan (BI) now going for index seek (AI), and
total execution time came down from 9 sec to 1 sec. But CPU is going to
100%, I am guessing does the new index made all other queries to run slow. I
dont worry about INSERT/DELETE/UPDATE, I need to tune SELECT stmts only
(the data is very static). Is SQL Server not intelligent to ignore indexes
that are not useful in plan preparation. If i create a new index it looks
like other queries which joins this table are going to wrong execution
plans. Please help.
Thanks,
Subbu
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:OltKJu1XGHA.4652@.TK2MSFTNGP04.phx.gbl...
> You might just have gotten a bad plan. I would try it again.
> --
> Andrew J. Kelly SQL MVP
>
> "subbu" <subbaiahd@.hotmail.com> wrote in message
> news:%235Pf63zXGHA.3516@.TK2MSFTNGP03.phx.gbl...
>|||How many CPU's do you have? It's possible that parallelism is being used
suboptimally. I'd use the Profiler to find which queries are being
affected. For those, you may want to use OPTION (MAXDOP 1).
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"subbu" <subbaiahd@.hotmail.com> wrote in message
news:uLyApr8XGHA.4920@.TK2MSFTNGP02.phx.gbl...
(BI = Before Index Created
AI = After Index created)
The query for which i have created index is executing faster AI. the query
which was going for index scan (BI) now going for index seek (AI), and
total execution time came down from 9 sec to 1 sec. But CPU is going to
100%, I am guessing does the new index made all other queries to run slow. I
dont worry about INSERT/DELETE/UPDATE, I need to tune SELECT stmts only
(the data is very static). Is SQL Server not intelligent to ignore indexes
that are not useful in plan preparation. If i create a new index it looks
like other queries which joins this table are going to wrong execution
plans. Please help.
Thanks,
Subbu
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:OltKJu1XGHA.4652@.TK2MSFTNGP04.phx.gbl...
> You might just have gotten a bad plan. I would try it again.
> --
> Andrew J. Kelly SQL MVP
>
> "subbu" <subbaiahd@.hotmail.com> wrote in message
> news:%235Pf63zXGHA.3516@.TK2MSFTNGP03.phx.gbl...
>|||Thanks for the idea, i have one cpu.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23H$8I$8XGHA.128@.TK2MSFTNGP05.phx.gbl...
> How many CPU's do you have? It's possible that parallelism is being used
> suboptimally. I'd use the Profiler to find which queries are being
> affected. For those, you may want to use OPTION (MAXDOP 1).
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> .
> "subbu" <subbaiahd@.hotmail.com> wrote in message
> news:uLyApr8XGHA.4920@.TK2MSFTNGP02.phx.gbl...
> (BI = Before Index Created
> AI = After Index created)
>
> The query for which i have created index is executing faster AI. the query
> which was going for index scan (BI) now going for index seek (AI), and
> total execution time came down from 9 sec to 1 sec. But CPU is going to
> 100%, I am guessing does the new index made all other queries to run slow.
I
> dont worry about INSERT/DELETE/UPDATE, I need to tune SELECT stmts only
> (the data is very static). Is SQL Server not intelligent to ignore indexes
> that are not useful in plan preparation. If i create a new index it looks
> like other queries which joins this table are going to wrong execution
> plans. Please help.
> Thanks,
> Subbu
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:OltKJu1XGHA.4652@.TK2MSFTNGP04.phx.gbl...
after[vbcol=seagreen]
how[vbcol=seagreen]
>|||Well, it's not parallelism, then. I'd still use the profiler to figure out
where the bones are buried.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"subbu" <subbaiahd@.hotmail.com> wrote in message
news:eoh%23Ks9XGHA.4248@.TK2MSFTNGP05.phx.gbl...
Thanks for the idea, i have one cpu.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23H$8I$8XGHA.128@.TK2MSFTNGP05.phx.gbl...
> How many CPU's do you have? It's possible that parallelism is being used
> suboptimally. I'd use the Profiler to find which queries are being
> affected. For those, you may want to use OPTION (MAXDOP 1).
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> .
> "subbu" <subbaiahd@.hotmail.com> wrote in message
> news:uLyApr8XGHA.4920@.TK2MSFTNGP02.phx.gbl...
> (BI = Before Index Created
> AI = After Index created)
>
> The query for which i have created index is executing faster AI. the query
> which was going for index scan (BI) now going for index seek (AI), and
> total execution time came down from 9 sec to 1 sec. But CPU is going to
> 100%, I am guessing does the new index made all other queries to run slow.
I
> dont worry about INSERT/DELETE/UPDATE, I need to tune SELECT stmts only
> (the data is very static). Is SQL Server not intelligent to ignore indexes
> that are not useful in plan preparation. If i create a new index it looks
> like other queries which joins this table are going to wrong execution
> plans. Please help.
> Thanks,
> Subbu
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:OltKJu1XGHA.4652@.TK2MSFTNGP04.phx.gbl...
after[vbcol=seagreen]
how[vbcol=seagreen]
>|||If you query originally took 9 seconds and now takes 1 then you must be
returning a lot of rows. The CPU going to 100% is probably just a sign that
it is now able to process more efficiently and thus faster. If no one lese
is on the server and you issue the query and the CPU spikes to 100% for 1
second and then drops to 0 everything is OK.
Andrew J. Kelly SQL MVP
"subbu" <subbaiahd@.hotmail.com> wrote in message
news:uLyApr8XGHA.4920@.TK2MSFTNGP02.phx.gbl...
> (BI = Before Index Created
> AI = After Index created)
>
> The query for which i have created index is executing faster AI. the query
> which was going for index scan (BI) now going for index seek (AI), and
> total execution time came down from 9 sec to 1 sec. But CPU is going to
> 100%, I am guessing does the new index made all other queries to run slow.
> I
> dont worry about INSERT/DELETE/UPDATE, I need to tune SELECT stmts only
> (the data is very static). Is SQL Server not intelligent to ignore indexes
> that are not useful in plan preparation. If i create a new index it looks
> like other queries which joins this table are going to wrong execution
> plans. Please help.
> Thanks,
> Subbu
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:OltKJu1XGHA.4652@.TK2MSFTNGP04.phx.gbl...
>

Covering indexes in SQL Server 2005

Hi,
To look up information about indexes for a given table in SQL Server
2005, I can use:
sp_helpindex TableName
or
select * from sys.indexes where object_id = object_id('TableName')
But this just gives me information about the column or columns on which
the index has been defined. How do I find out what columns may have
been included in the index?
For example, if I created the following index:
CREATE INDEX IX_1 ON TableName(ColA) INCLUDE(ColB)
Where will I find complete information about IX_1 - which also
indicates whether this is a covering index and if yes - what columns
were included?
Thanks much,
SmithaHi Smitha
You'll need to join sys.indexes with sys.index_columns, and sys.columns.
Here is a view I created to do that:
CREATE VIEW get_index_columns
AS
SELECT object_name(ic.object_id) as object_name , index_name = i.name,
'column' = c.name, 'column usage' = CASE ic.is_included_column
WHEN 0 then 'KEY'
ELSE 'INCLUDED'
END
FROM sys.index_columns ic JOIN sys.columns c
ON ic.object_id = c.object_id
AND ic.column_id = c.column_id
JOIN sys.indexes i
ON i.object_id = ic.object_id
AND i.index_id = ic.index_id
So after creating this view, you can use it as follows:
SELECT * FROM get_index_columns
WHERE object_name = 'TableName'
--
HTH
Kalen Delaney, SQL Server MVP
<smithabreddy@.gmail.com> wrote in message
news:1155047736.933287.185730@.i42g2000cwa.googlegroups.com...
> Hi,
> To look up information about indexes for a given table in SQL Server
> 2005, I can use:
> sp_helpindex TableName
> or
> select * from sys.indexes where object_id = object_id('TableName')
> But this just gives me information about the column or columns on which
> the index has been defined. How do I find out what columns may have
> been included in the index?
> For example, if I created the following index:
> CREATE INDEX IX_1 ON TableName(ColA) INCLUDE(ColB)
> Where will I find complete information about IX_1 - which also
> indicates whether this is a covering index and if yes - what columns
> were included?
> Thanks much,
> Smitha
>|||Hi
Check out sys.index_columns and the is_included_column bit/
John
"smithabreddy@.gmail.com" wrote:
> Hi,
> To look up information about indexes for a given table in SQL Server
> 2005, I can use:
> sp_helpindex TableName
> or
> select * from sys.indexes where object_id = object_id('TableName')
> But this just gives me information about the column or columns on which
> the index has been defined. How do I find out what columns may have
> been included in the index?
> For example, if I created the following index:
> CREATE INDEX IX_1 ON TableName(ColA) INCLUDE(ColB)
> Where will I find complete information about IX_1 - which also
> indicates whether this is a covering index and if yes - what columns
> were included?
> Thanks much,
> Smitha
>

Covering indexes in SQL Server 2005

Hi,
To look up information about indexes for a given table in SQL Server
2005, I can use:
sp_helpindex TableName
or
select * from sys.indexes where object_id = object_id('TableName')
But this just gives me information about the column or columns on which
the index has been defined. How do I find out what columns may have
been included in the index?
For example, if I created the following index:
CREATE INDEX IX_1 ON TableName(ColA) INCLUDE(ColB)
Where will I find complete information about IX_1 - which also
indicates whether this is a covering index and if yes - what columns
were included?
Thanks much,
SmithaHi Smitha
You'll need to join sys.indexes with sys.index_columns, and sys.columns.
Here is a view I created to do that:
CREATE VIEW get_index_columns
AS
SELECT object_name(ic.object_id) as object_name , index_name = i.name,
'column' = c.name, 'column usage' = CASE ic.is_included_column
WHEN 0 then 'KEY'
ELSE 'INCLUDED'
END
FROM sys.index_columns ic JOIN sys.columns c
ON ic.object_id = c.object_id
AND ic.column_id = c.column_id
JOIN sys.indexes i
ON i.object_id = ic.object_id
AND i.index_id = ic.index_id
So after creating this view, you can use it as follows:
SELECT * FROM get_index_columns
WHERE object_name = 'TableName'
HTH
Kalen Delaney, SQL Server MVP
<smithabreddy@.gmail.com> wrote in message
news:1155047736.933287.185730@.i42g2000cwa.googlegroups.com...
> Hi,
> To look up information about indexes for a given table in SQL Server
> 2005, I can use:
> sp_helpindex TableName
> or
> select * from sys.indexes where object_id = object_id('TableName')
> But this just gives me information about the column or columns on which
> the index has been defined. How do I find out what columns may have
> been included in the index?
> For example, if I created the following index:
> CREATE INDEX IX_1 ON TableName(ColA) INCLUDE(ColB)
> Where will I find complete information about IX_1 - which also
> indicates whether this is a covering index and if yes - what columns
> were included?
> Thanks much,
> Smitha
>|||Hi
Check out sys.index_columns and the is_included_column bit/
John
"smithabreddy@.gmail.com" wrote:

> Hi,
> To look up information about indexes for a given table in SQL Server
> 2005, I can use:
> sp_helpindex TableName
> or
> select * from sys.indexes where object_id = object_id('TableName')
> But this just gives me information about the column or columns on which
> the index has been defined. How do I find out what columns may have
> been included in the index?
> For example, if I created the following index:
> CREATE INDEX IX_1 ON TableName(ColA) INCLUDE(ColB)
> Where will I find complete information about IX_1 - which also
> indicates whether this is a covering index and if yes - what columns
> were included?
> Thanks much,
> Smitha
>

covering indexes

Hi,
I asked the similar question before but I have again some doubts about covering indexes.
Besides, tomorrow I have a Microsoft MCAD 70-229 exam so please help me.
In here,
SELECT * FROM Order WHERE OrderID > 12 ORDER BY OrderDate

we create composite nonclustered index for both OrderID and OrderDate column.
Leftmost is OrderID.
So

when our first research is happening(Where clause), the only

nonclustered index which is used is OrderID index. And then, when we

pass through the second search(ORDER BY clause), OrderDate index become activated.
So

we can say that the seleection of indexes in composite indexes is

determined according to the situation of the query at that time.

Hence, is this all correct ?

Best wishes,
Mert

Hmm,
Now thanks to the strict studies on indexes, I conceived that my approach to this is completely false.
So again in my opinion, the best solution for the above query is that we must use two separate indexes and for Ordeing we should use nonclustered index since it brings much performance benefit, for instance; we do not have to look up the data table since we will have a available ordered set.
So would you please explain your own opinions ?

Thanks

covering indexes

In lot of atricles regarding sql server performacne i read about "consider
using covering indexes" .
my question is How do u create a covering index, can we create it explicitly
or
sql server creates it automatically?
Thanks
Sri
Hi Sri
I'm a bit surprised that you read lots of articles that suggest creating
covering indexes, but you've never read one that told you what a covering
index is.
A covering index is one that includes ALL the columns from a table that are
used in a query. Normally, all that is important for an index to be used is
that the index keys are referenced in your WHERE clause, but with a
covering index, ALL the columns (from the SELECT list, the GROUP BY and any
other clause of your query) are part of the nonclustered index. Because the
covering index has everything needed to satisfy your query, SQL Server never
needs to access the actual data pages; it can stay in the index to retrieve
all the results.
So you need to examine your queries that aren't using any of your indexes,
and see if you can create one or more indexes that cover them. SQL Server
will not create these indexes automatically (unless you think of
automatically as following suggestions of the Index Tuning Wizard.)
HTH
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Sri" <Sri@.discussions.microsoft.com> wrote in message
news:9EC780A6-9458-4A9A-A85E-0E241A1308A9@.microsoft.com...
> In lot of atricles regarding sql server performacne i read about "consider
> using covering indexes" .
> my question is How do u create a covering index, can we create it
> explicitly
> or
> sql server creates it automatically?
>
> Thanks
> Sri
>
>
|||"Sri" <Sri@.discussions.microsoft.com> wrote in message
news:9EC780A6-9458-4A9A-A85E-0E241A1308A9@.microsoft.com...
> In lot of atricles regarding sql server performacne i read about "consider
> using covering indexes" .
> my question is How do u create a covering index, can we create it
explicitly
> or
> sql server creates it automatically?
>
Further to Kalens excellent reply, it does not have to be just one
non-clustered index. SQL can combine multiple non-clustered indexes to
cover the query.
Also the key to row ratio affects performance. If there are 2 columns
referenced in the query but 50 in the underlying table it will be faster
covering it than if there are 40 columns referenced in the query. Try to
avoid SELECT *.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 15/10/2004

covering indexes

In lot of atricles regarding sql server performacne i read about "consider
using covering indexes" .
my question is How do u create a covering index, can we create it explicitly
or
sql server creates it automatically?
Thanks
SriHi Sri
I'm a bit surprised that you read lots of articles that suggest creating
covering indexes, but you've never read one that told you what a covering
index is.
A covering index is one that includes ALL the columns from a table that are
used in a query. Normally, all that is important for an index to be used is
that the index keys are referenced in your WHERE clause, but with a
covering index, ALL the columns (from the SELECT list, the GROUP BY and any
other clause of your query) are part of the nonclustered index. Because the
covering index has everything needed to satisfy your query, SQL Server never
needs to access the actual data pages; it can stay in the index to retrieve
all the results.
So you need to examine your queries that aren't using any of your indexes,
and see if you can create one or more indexes that cover them. SQL Server
will not create these indexes automatically (unless you think of
automatically as following suggestions of the Index Tuning Wizard.)
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Sri" <Sri@.discussions.microsoft.com> wrote in message
news:9EC780A6-9458-4A9A-A85E-0E241A1308A9@.microsoft.com...
> In lot of atricles regarding sql server performacne i read about "consider
> using covering indexes" .
> my question is How do u create a covering index, can we create it
> explicitly
> or
> sql server creates it automatically?
>
> Thanks
> Sri
>
>|||"Sri" <Sri@.discussions.microsoft.com> wrote in message
news:9EC780A6-9458-4A9A-A85E-0E241A1308A9@.microsoft.com...
> In lot of atricles regarding sql server performacne i read about "consider
> using covering indexes" .
> my question is How do u create a covering index, can we create it
explicitly
> or
> sql server creates it automatically?
>
Further to Kalens excellent reply, it does not have to be just one
non-clustered index. SQL can combine multiple non-clustered indexes to
cover the query.
Also the key to row ratio affects performance. If there are 2 columns
referenced in the query but 50 in the underlying table it will be faster
covering it than if there are 40 columns referenced in the query. Try to
avoid SELECT *.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 15/10/2004

covering indexes

In lot of atricles regarding sql server performacne i read about "consider
using covering indexes" .
my question is How do u create a covering index, can we create it explicitly
or
sql server creates it automatically?
Thanks
SriHi Sri
I'm a bit surprised that you read lots of articles that suggest creating
covering indexes, but you've never read one that told you what a covering
index is.
A covering index is one that includes ALL the columns from a table that are
used in a query. Normally, all that is important for an index to be used is
that the index keys are referenced in your WHERE clause, but with a
covering index, ALL the columns (from the SELECT list, the GROUP BY and any
other clause of your query) are part of the nonclustered index. Because the
covering index has everything needed to satisfy your query, SQL Server never
needs to access the actual data pages; it can stay in the index to retrieve
all the results.
So you need to examine your queries that aren't using any of your indexes,
and see if you can create one or more indexes that cover them. SQL Server
will not create these indexes automatically (unless you think of
automatically as following suggestions of the Index Tuning Wizard.)
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Sri" <Sri@.discussions.microsoft.com> wrote in message
news:9EC780A6-9458-4A9A-A85E-0E241A1308A9@.microsoft.com...
> In lot of atricles regarding sql server performacne i read about "consider
> using covering indexes" .
> my question is How do u create a covering index, can we create it
> explicitly
> or
> sql server creates it automatically?
>
> Thanks
> Sri
>
>|||"Sri" <Sri@.discussions.microsoft.com> wrote in message
news:9EC780A6-9458-4A9A-A85E-0E241A1308A9@.microsoft.com...
> In lot of atricles regarding sql server performacne i read about "consider
> using covering indexes" .
> my question is How do u create a covering index, can we create it
explicitly
> or
> sql server creates it automatically?
>
Further to Kalens excellent reply, it does not have to be just one
non-clustered index. SQL can combine multiple non-clustered indexes to
cover the query.
Also the key to row ratio affects performance. If there are 2 columns
referenced in the query but 50 in the underlying table it will be faster
covering it than if there are 40 columns referenced in the query. Try to
avoid SELECT *.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 15/10/2004