Hello
I try to attach a database and the following error occurs:
Server: Msg 644, Level 21, State 5, Line 1
Could not find the index entry for RID '16a5eed57f3000300' in index page
(1:29375), index ID 8, database 'mat'.
26 transactions rolled forward in database 'mat' (10).
Connection Broken
Can anyone help me?The database was most probably corrupt when you detached it. Search the new
updated Books Online for
specific recommendations for your particular error number. consider opening
a case with MS Support.
Also, you might want to check http://www.karaszi.com/SQLServer/in...br />
t_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"koletsis theo" <koletsis theo@.discussions.microsoft.com> wrote in message
news:393BC089-3F37-4EBA-AA3D-66D51A6E9655@.microsoft.com...
> Hello
> I try to attach a database and the following error occurs:
> Server: Msg 644, Level 21, State 5, Line 1
> Could not find the index entry for RID '16a5eed57f3000300' in index page
> (1:29375), index ID 8, database 'mat'.
> 26 transactions rolled forward in database 'mat' (10).
> Connection Broken
> Can anyone help me?
>
>|||In addition , I'm sure you have last backup of the database.
"koletsis theo" <koletsis theo@.discussions.microsoft.com> wrote in message
news:393BC089-3F37-4EBA-AA3D-66D51A6E9655@.microsoft.com...
> Hello
> I try to attach a database and the following error occurs:
> Server: Msg 644, Level 21, State 5, Line 1
> Could not find the index entry for RID '16a5eed57f3000300' in index page
> (1:29375), index ID 8, database 'mat'.
> 26 transactions rolled forward in database 'mat' (10).
> Connection Broken
> Can anyone help me?
>
>
Showing posts with label index. Show all posts
Showing posts with label index. Show all posts
Tuesday, March 27, 2012
ATTACH DB ERROR
Hello
I try to attach a database and the following error occurs:
Server: Msg 644, Level 21, State 5, Line 1
Could not find the index entry for RID '16a5eed57f3000300' in index page
(1:29375), index ID 8, database 'mat'.
26 transactions rolled forward in database 'mat' (10).
Connection Broken
Can anyone help me?The database was most probably corrupt when you detached it. Search the new updated Books Online for
specific recommendations for your particular error number. consider opening a case with MS Support.
Also, you might want to check http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"koletsis theo" <koletsis theo@.discussions.microsoft.com> wrote in message
news:393BC089-3F37-4EBA-AA3D-66D51A6E9655@.microsoft.com...
> Hello
> I try to attach a database and the following error occurs:
> Server: Msg 644, Level 21, State 5, Line 1
> Could not find the index entry for RID '16a5eed57f3000300' in index page
> (1:29375), index ID 8, database 'mat'.
> 26 transactions rolled forward in database 'mat' (10).
> Connection Broken
> Can anyone help me?
>
>|||In addition , I'm sure you have last backup of the database.
"koletsis theo" <koletsis theo@.discussions.microsoft.com> wrote in message
news:393BC089-3F37-4EBA-AA3D-66D51A6E9655@.microsoft.com...
> Hello
> I try to attach a database and the following error occurs:
> Server: Msg 644, Level 21, State 5, Line 1
> Could not find the index entry for RID '16a5eed57f3000300' in index page
> (1:29375), index ID 8, database 'mat'.
> 26 transactions rolled forward in database 'mat' (10).
> Connection Broken
> Can anyone help me?
>
>
I try to attach a database and the following error occurs:
Server: Msg 644, Level 21, State 5, Line 1
Could not find the index entry for RID '16a5eed57f3000300' in index page
(1:29375), index ID 8, database 'mat'.
26 transactions rolled forward in database 'mat' (10).
Connection Broken
Can anyone help me?The database was most probably corrupt when you detached it. Search the new updated Books Online for
specific recommendations for your particular error number. consider opening a case with MS Support.
Also, you might want to check http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"koletsis theo" <koletsis theo@.discussions.microsoft.com> wrote in message
news:393BC089-3F37-4EBA-AA3D-66D51A6E9655@.microsoft.com...
> Hello
> I try to attach a database and the following error occurs:
> Server: Msg 644, Level 21, State 5, Line 1
> Could not find the index entry for RID '16a5eed57f3000300' in index page
> (1:29375), index ID 8, database 'mat'.
> 26 transactions rolled forward in database 'mat' (10).
> Connection Broken
> Can anyone help me?
>
>|||In addition , I'm sure you have last backup of the database.
"koletsis theo" <koletsis theo@.discussions.microsoft.com> wrote in message
news:393BC089-3F37-4EBA-AA3D-66D51A6E9655@.microsoft.com...
> Hello
> I try to attach a database and the following error occurs:
> Server: Msg 644, Level 21, State 5, Line 1
> Could not find the index entry for RID '16a5eed57f3000300' in index page
> (1:29375), index ID 8, database 'mat'.
> 26 transactions rolled forward in database 'mat' (10).
> Connection Broken
> Can anyone help me?
>
>
ATTACH DB ERROR
Hello
I try to attach a database and the following error occurs:
Server: Msg 644, Level 21, State 5, Line 1
Could not find the index entry for RID '16a5eed57f3000300' in index page
(1:29375), index ID 8, database 'mat'.
26 transactions rolled forward in database 'mat' (10).
Connection Broken
Can anyone help me?
The database was most probably corrupt when you detached it. Search the new updated Books Online for
specific recommendations for your particular error number. consider opening a case with MS Support.
Also, you might want to check http://www.karaszi.com/SQLServer/inf...suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"koletsis theo" <koletsis theo@.discussions.microsoft.com> wrote in message
news:393BC089-3F37-4EBA-AA3D-66D51A6E9655@.microsoft.com...
> Hello
> I try to attach a database and the following error occurs:
> Server: Msg 644, Level 21, State 5, Line 1
> Could not find the index entry for RID '16a5eed57f3000300' in index page
> (1:29375), index ID 8, database 'mat'.
> 26 transactions rolled forward in database 'mat' (10).
> Connection Broken
> Can anyone help me?
>
>
|||In addition , I'm sure you have last backup of the database.
"koletsis theo" <koletsis theo@.discussions.microsoft.com> wrote in message
news:393BC089-3F37-4EBA-AA3D-66D51A6E9655@.microsoft.com...
> Hello
> I try to attach a database and the following error occurs:
> Server: Msg 644, Level 21, State 5, Line 1
> Could not find the index entry for RID '16a5eed57f3000300' in index page
> (1:29375), index ID 8, database 'mat'.
> 26 transactions rolled forward in database 'mat' (10).
> Connection Broken
> Can anyone help me?
>
>
I try to attach a database and the following error occurs:
Server: Msg 644, Level 21, State 5, Line 1
Could not find the index entry for RID '16a5eed57f3000300' in index page
(1:29375), index ID 8, database 'mat'.
26 transactions rolled forward in database 'mat' (10).
Connection Broken
Can anyone help me?
The database was most probably corrupt when you detached it. Search the new updated Books Online for
specific recommendations for your particular error number. consider opening a case with MS Support.
Also, you might want to check http://www.karaszi.com/SQLServer/inf...suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"koletsis theo" <koletsis theo@.discussions.microsoft.com> wrote in message
news:393BC089-3F37-4EBA-AA3D-66D51A6E9655@.microsoft.com...
> Hello
> I try to attach a database and the following error occurs:
> Server: Msg 644, Level 21, State 5, Line 1
> Could not find the index entry for RID '16a5eed57f3000300' in index page
> (1:29375), index ID 8, database 'mat'.
> 26 transactions rolled forward in database 'mat' (10).
> Connection Broken
> Can anyone help me?
>
>
|||In addition , I'm sure you have last backup of the database.
"koletsis theo" <koletsis theo@.discussions.microsoft.com> wrote in message
news:393BC089-3F37-4EBA-AA3D-66D51A6E9655@.microsoft.com...
> Hello
> I try to attach a database and the following error occurs:
> Server: Msg 644, Level 21, State 5, Line 1
> Could not find the index entry for RID '16a5eed57f3000300' in index page
> (1:29375), index ID 8, database 'mat'.
> 26 transactions rolled forward in database 'mat' (10).
> Connection Broken
> Can anyone help me?
>
>
Thursday, March 22, 2012
atabase Tuning ADvisor and index recommendations
Hi there. I love this tool from what I've read, will it also tell me what indexes I DON'T need (I think that would be helpful - especially when I'm not the one creating indexes all the time). Thanks!Moving to tools forum.|||
More or less it does as per my experience, but in this case you might need to run thru full analysis using the profiler trace.
Refer to http://blogs.msdn.com/sqlcat/archive/2006/02/13/531339.aspx for more information.
Tuesday, March 20, 2012
Assumptions on Indexing
I create the following:
CREATE TABLE t1(c1 INT, c2 INT, c3 INT)
CREATE CLUSTERED INDEX icl ON t1(c3)
CREATE NONCLUSTERED INDEX incl ON t1(C1, c2)
When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
the following columns:
c1, c2, c3
ASSUMPTION #1: I assume the reason for this is that clustered index columns
(in this case, c3) are appended to the end of nonclustered index columns as
a
row locator.
Why then, if the above assumption [ASSUMPTION #1] is true, when I perfor
m the
following:
CREATE NONCLUSTERED INDEX incl ON t1(C1, c3, c2) --Take note of the non-
sequential column order
WITH DROP_EXISTING
When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
the following columns:
c1, c3, c2
ASSUMPTION #2: Based upon Assumption #1, I would expect to see the clustered
index column of c3 appended to the end of the nonclustered index column,
meaning I expected to see c1, c3, c2, c3. Since that was not the case, I
assume the reason the clustered index was not appended was due to its [t
he
clustered index] being included in the nonclustered index, and appending
column c3 [the clustered index column] to the nonclustered index in
DBCC_SHOW_STATISTICS would be redundant.
Are the above assumptions true?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200604/1> Are the above assumptions true?
Yes and yes.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"cbrichards via droptable.com" <u3288@.uwe> wrote in message news:5e86871f6f516@.uwe...[vbcol
=seagreen]
>I create the following:
> CREATE TABLE t1(c1 INT, c2 INT, c3 INT)
> CREATE CLUSTERED INDEX icl ON t1(c3)
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c2)
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c2, c3
> ASSUMPTION #1: I assume the reason for this is that clustered index column
s
> (in this case, c3) are appended to the end of nonclustered index columns a
s a
> row locator.
> Why then, if the above assumption [ASSUMPTION #1] is true, when I perf
orm the
> following:
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c3, c2) --Take note of the non-
> sequential column order
> WITH DROP_EXISTING
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c3, c2
> ASSUMPTION #2: Based upon Assumption #1, I would expect to see the cluster
ed
> index column of c3 appended to the end of the nonclustered index column,
> meaning I expected to see c1, c3, c2, c3. Since that was not the case, I
> assume the reason the clustered index was not appended was due to its [
;the
> clustered index] being included in the nonclustered index, and appending
> column c3 [the clustered index column] to the nonclustered index in
> DBCC_SHOW_STATISTICS would be redundant.
> Are the above assumptions true?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200604/1[/vbcol]|||Yep. The clustered key(s) is always included in the nonclustered, but it
doesn't always have to be the right-most column.
HTH
Kalen Delaney, SQL Server MVP
www.solidqualitylearning.com
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:5e86871f6f516@.uwe...
>I create the following:
> CREATE TABLE t1(c1 INT, c2 INT, c3 INT)
> CREATE CLUSTERED INDEX icl ON t1(c3)
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c2)
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c2, c3
> ASSUMPTION #1: I assume the reason for this is that clustered index
> columns
> (in this case, c3) are appended to the end of nonclustered index columns
> as a
> row locator.
> Why then, if the above assumption [ASSUMPTION #1] is true, when I perf
orm
> the
> following:
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c3, c2) --Take note of the non-
> sequential column order
> WITH DROP_EXISTING
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c3, c2
> ASSUMPTION #2: Based upon Assumption #1, I would expect to see the
> clustered
> index column of c3 appended to the end of the nonclustered index column,
> meaning I expected to see c1, c3, c2, c3. Since that was not the case, I
> assume the reason the clustered index was not appended was due to its [
;the
> clustered index] being included in the nonclustered index, and appending
> column c3 [the clustered index column] to the nonclustered index in
> DBCC_SHOW_STATISTICS would be redundant.
> Are the above assumptions true?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200604/1|||sort of.
clustered indexes are weird. they physically sort the data, and then
use the columns as a key to find the relevant rows. all of this is
inherently inefficient.
non clustered indexes use data positions in the table to locate rows.
well, if there is a clustered index on the table, then those data
positions are determined by the clustered column.
so, if we create a non clustered index on the table, the engine MUST
HAVE the data elements from the clustered column in order to find the
correct row.
to see how this all works, and make it real in your head, right down
some 5 rows of examples, then create how the index would really work.
CREATE TABLE t1(c1 INT, c2 INT, c3 INT)
CREATE CLUSTERED INDEX icl ON t1(c3)
CREATE NONCLUSTERED INDEX incl ON t1(C1, c2)
When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
the following columns:
c1, c2, c3
ASSUMPTION #1: I assume the reason for this is that clustered index columns
(in this case, c3) are appended to the end of nonclustered index columns as
a
row locator.
Why then, if the above assumption [ASSUMPTION #1] is true, when I perfor
m the
following:
CREATE NONCLUSTERED INDEX incl ON t1(C1, c3, c2) --Take note of the non-
sequential column order
WITH DROP_EXISTING
When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
the following columns:
c1, c3, c2
ASSUMPTION #2: Based upon Assumption #1, I would expect to see the clustered
index column of c3 appended to the end of the nonclustered index column,
meaning I expected to see c1, c3, c2, c3. Since that was not the case, I
assume the reason the clustered index was not appended was due to its [t
he
clustered index] being included in the nonclustered index, and appending
column c3 [the clustered index column] to the nonclustered index in
DBCC_SHOW_STATISTICS would be redundant.
Are the above assumptions true?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200604/1> Are the above assumptions true?
Yes and yes.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"cbrichards via droptable.com" <u3288@.uwe> wrote in message news:5e86871f6f516@.uwe...[vbcol
=seagreen]
>I create the following:
> CREATE TABLE t1(c1 INT, c2 INT, c3 INT)
> CREATE CLUSTERED INDEX icl ON t1(c3)
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c2)
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c2, c3
> ASSUMPTION #1: I assume the reason for this is that clustered index column
s
> (in this case, c3) are appended to the end of nonclustered index columns a
s a
> row locator.
> Why then, if the above assumption [ASSUMPTION #1] is true, when I perf
orm the
> following:
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c3, c2) --Take note of the non-
> sequential column order
> WITH DROP_EXISTING
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c3, c2
> ASSUMPTION #2: Based upon Assumption #1, I would expect to see the cluster
ed
> index column of c3 appended to the end of the nonclustered index column,
> meaning I expected to see c1, c3, c2, c3. Since that was not the case, I
> assume the reason the clustered index was not appended was due to its [
;the
> clustered index] being included in the nonclustered index, and appending
> column c3 [the clustered index column] to the nonclustered index in
> DBCC_SHOW_STATISTICS would be redundant.
> Are the above assumptions true?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200604/1[/vbcol]|||Yep. The clustered key(s) is always included in the nonclustered, but it
doesn't always have to be the right-most column.
HTH
Kalen Delaney, SQL Server MVP
www.solidqualitylearning.com
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:5e86871f6f516@.uwe...
>I create the following:
> CREATE TABLE t1(c1 INT, c2 INT, c3 INT)
> CREATE CLUSTERED INDEX icl ON t1(c3)
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c2)
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c2, c3
> ASSUMPTION #1: I assume the reason for this is that clustered index
> columns
> (in this case, c3) are appended to the end of nonclustered index columns
> as a
> row locator.
> Why then, if the above assumption [ASSUMPTION #1] is true, when I perf
orm
> the
> following:
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c3, c2) --Take note of the non-
> sequential column order
> WITH DROP_EXISTING
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c3, c2
> ASSUMPTION #2: Based upon Assumption #1, I would expect to see the
> clustered
> index column of c3 appended to the end of the nonclustered index column,
> meaning I expected to see c1, c3, c2, c3. Since that was not the case, I
> assume the reason the clustered index was not appended was due to its [
;the
> clustered index] being included in the nonclustered index, and appending
> column c3 [the clustered index column] to the nonclustered index in
> DBCC_SHOW_STATISTICS would be redundant.
> Are the above assumptions true?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200604/1|||sort of.
clustered indexes are weird. they physically sort the data, and then
use the columns as a key to find the relevant rows. all of this is
inherently inefficient.
non clustered indexes use data positions in the table to locate rows.
well, if there is a clustered index on the table, then those data
positions are determined by the clustered column.
so, if we create a non clustered index on the table, the engine MUST
HAVE the data elements from the clustered column in order to find the
correct row.
to see how this all works, and make it real in your head, right down
some 5 rows of examples, then create how the index would really work.
Assumptions on Indexing
I create the following:
CREATE TABLE t1(c1 INT, c2 INT, c3 INT)
CREATE CLUSTERED INDEX icl ON t1(c3)
CREATE NONCLUSTERED INDEX incl ON t1(C1, c2)
When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
the following columns:
c1, c2, c3
ASSUMPTION #1: I assume the reason for this is that clustered index columns
(in this case, c3) are appended to the end of nonclustered index columns as a
row locator.
Why then, if the above assumption [ASSUMPTION #1] is true, when I perform the
following:
CREATE NONCLUSTERED INDEX incl ON t1(C1, c3, c2) --Take note of the non-
sequential column order
WITH DROP_EXISTING
When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
the following columns:
c1, c3, c2
ASSUMPTION #2: Based upon Assumption #1, I would expect to see the clustered
index column of c3 appended to the end of the nonclustered index column,
meaning I expected to see c1, c3, c2, c3. Since that was not the case, I
assume the reason the clustered index was not appended was due to its [the
clustered index] being included in the nonclustered index, and appending
column c3 [the clustered index column] to the nonclustered index in
DBCC_SHOW_STATISTICS would be redundant.
Are the above assumptions true?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200604/1> Are the above assumptions true?
Yes and yes.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message news:5e86871f6f516@.uwe...
>I create the following:
> CREATE TABLE t1(c1 INT, c2 INT, c3 INT)
> CREATE CLUSTERED INDEX icl ON t1(c3)
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c2)
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c2, c3
> ASSUMPTION #1: I assume the reason for this is that clustered index columns
> (in this case, c3) are appended to the end of nonclustered index columns as a
> row locator.
> Why then, if the above assumption [ASSUMPTION #1] is true, when I perform the
> following:
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c3, c2) --Take note of the non-
> sequential column order
> WITH DROP_EXISTING
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c3, c2
> ASSUMPTION #2: Based upon Assumption #1, I would expect to see the clustered
> index column of c3 appended to the end of the nonclustered index column,
> meaning I expected to see c1, c3, c2, c3. Since that was not the case, I
> assume the reason the clustered index was not appended was due to its [the
> clustered index] being included in the nonclustered index, and appending
> column c3 [the clustered index column] to the nonclustered index in
> DBCC_SHOW_STATISTICS would be redundant.
> Are the above assumptions true?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200604/1|||Yep. The clustered key(s) is always included in the nonclustered, but it
doesn't always have to be the right-most column.
--
HTH
Kalen Delaney, SQL Server MVP
www.solidqualitylearning.com
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:5e86871f6f516@.uwe...
>I create the following:
> CREATE TABLE t1(c1 INT, c2 INT, c3 INT)
> CREATE CLUSTERED INDEX icl ON t1(c3)
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c2)
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c2, c3
> ASSUMPTION #1: I assume the reason for this is that clustered index
> columns
> (in this case, c3) are appended to the end of nonclustered index columns
> as a
> row locator.
> Why then, if the above assumption [ASSUMPTION #1] is true, when I perform
> the
> following:
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c3, c2) --Take note of the non-
> sequential column order
> WITH DROP_EXISTING
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c3, c2
> ASSUMPTION #2: Based upon Assumption #1, I would expect to see the
> clustered
> index column of c3 appended to the end of the nonclustered index column,
> meaning I expected to see c1, c3, c2, c3. Since that was not the case, I
> assume the reason the clustered index was not appended was due to its [the
> clustered index] being included in the nonclustered index, and appending
> column c3 [the clustered index column] to the nonclustered index in
> DBCC_SHOW_STATISTICS would be redundant.
> Are the above assumptions true?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200604/1|||sort of.
clustered indexes are weird. they physically sort the data, and then
use the columns as a key to find the relevant rows. all of this is
inherently inefficient.
non clustered indexes use data positions in the table to locate rows.
well, if there is a clustered index on the table, then those data
positions are determined by the clustered column.
so, if we create a non clustered index on the table, the engine MUST
HAVE the data elements from the clustered column in order to find the
correct row.
to see how this all works, and make it real in your head, right down
some 5 rows of examples, then create how the index would really work.sql
CREATE TABLE t1(c1 INT, c2 INT, c3 INT)
CREATE CLUSTERED INDEX icl ON t1(c3)
CREATE NONCLUSTERED INDEX incl ON t1(C1, c2)
When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
the following columns:
c1, c2, c3
ASSUMPTION #1: I assume the reason for this is that clustered index columns
(in this case, c3) are appended to the end of nonclustered index columns as a
row locator.
Why then, if the above assumption [ASSUMPTION #1] is true, when I perform the
following:
CREATE NONCLUSTERED INDEX incl ON t1(C1, c3, c2) --Take note of the non-
sequential column order
WITH DROP_EXISTING
When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
the following columns:
c1, c3, c2
ASSUMPTION #2: Based upon Assumption #1, I would expect to see the clustered
index column of c3 appended to the end of the nonclustered index column,
meaning I expected to see c1, c3, c2, c3. Since that was not the case, I
assume the reason the clustered index was not appended was due to its [the
clustered index] being included in the nonclustered index, and appending
column c3 [the clustered index column] to the nonclustered index in
DBCC_SHOW_STATISTICS would be redundant.
Are the above assumptions true?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200604/1> Are the above assumptions true?
Yes and yes.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message news:5e86871f6f516@.uwe...
>I create the following:
> CREATE TABLE t1(c1 INT, c2 INT, c3 INT)
> CREATE CLUSTERED INDEX icl ON t1(c3)
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c2)
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c2, c3
> ASSUMPTION #1: I assume the reason for this is that clustered index columns
> (in this case, c3) are appended to the end of nonclustered index columns as a
> row locator.
> Why then, if the above assumption [ASSUMPTION #1] is true, when I perform the
> following:
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c3, c2) --Take note of the non-
> sequential column order
> WITH DROP_EXISTING
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c3, c2
> ASSUMPTION #2: Based upon Assumption #1, I would expect to see the clustered
> index column of c3 appended to the end of the nonclustered index column,
> meaning I expected to see c1, c3, c2, c3. Since that was not the case, I
> assume the reason the clustered index was not appended was due to its [the
> clustered index] being included in the nonclustered index, and appending
> column c3 [the clustered index column] to the nonclustered index in
> DBCC_SHOW_STATISTICS would be redundant.
> Are the above assumptions true?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200604/1|||Yep. The clustered key(s) is always included in the nonclustered, but it
doesn't always have to be the right-most column.
--
HTH
Kalen Delaney, SQL Server MVP
www.solidqualitylearning.com
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:5e86871f6f516@.uwe...
>I create the following:
> CREATE TABLE t1(c1 INT, c2 INT, c3 INT)
> CREATE CLUSTERED INDEX icl ON t1(c3)
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c2)
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c2, c3
> ASSUMPTION #1: I assume the reason for this is that clustered index
> columns
> (in this case, c3) are appended to the end of nonclustered index columns
> as a
> row locator.
> Why then, if the above assumption [ASSUMPTION #1] is true, when I perform
> the
> following:
> CREATE NONCLUSTERED INDEX incl ON t1(C1, c3, c2) --Take note of the non-
> sequential column order
> WITH DROP_EXISTING
> When I perform a DBCC_SHOW_STATISTICS(t1, incl) the "Columns" column shows
> the following columns:
> c1, c3, c2
> ASSUMPTION #2: Based upon Assumption #1, I would expect to see the
> clustered
> index column of c3 appended to the end of the nonclustered index column,
> meaning I expected to see c1, c3, c2, c3. Since that was not the case, I
> assume the reason the clustered index was not appended was due to its [the
> clustered index] being included in the nonclustered index, and appending
> column c3 [the clustered index column] to the nonclustered index in
> DBCC_SHOW_STATISTICS would be redundant.
> Are the above assumptions true?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200604/1|||sort of.
clustered indexes are weird. they physically sort the data, and then
use the columns as a key to find the relevant rows. all of this is
inherently inefficient.
non clustered indexes use data positions in the table to locate rows.
well, if there is a clustered index on the table, then those data
positions are determined by the clustered column.
so, if we create a non clustered index on the table, the engine MUST
HAVE the data elements from the clustered column in order to find the
correct row.
to see how this all works, and make it real in your head, right down
some 5 rows of examples, then create how the index would really work.sql
Associative array
I have a variable declared as this:
type ltype_Queue is table of NUMBER index by binary_integer;
l_Queue ltype_Queue;
How can I accomplish the equivalent to this:
select *
from Items
where ID in l_Queue
Thanks,
Layneselect *
from Items
where ID in (select * from TABLE(cast(l_Queue as myTableType)));
where myTableType is a data type defined as below :
create type myTableType as table of varchar2(255)
/
Originally posted by lrobin3
I have a variable declared as this:
type ltype_Queue is table of NUMBER index by binary_integer;
l_Queue ltype_Queue;
How can I accomplish the equivalent to this:
select *
from Items
where ID in l_Queue
Thanks,
Layne
type ltype_Queue is table of NUMBER index by binary_integer;
l_Queue ltype_Queue;
How can I accomplish the equivalent to this:
select *
from Items
where ID in l_Queue
Thanks,
Layneselect *
from Items
where ID in (select * from TABLE(cast(l_Queue as myTableType)));
where myTableType is a data type defined as below :
create type myTableType as table of varchar2(255)
/
Originally posted by lrobin3
I have a variable declared as this:
type ltype_Queue is table of NUMBER index by binary_integer;
l_Queue ltype_Queue;
How can I accomplish the equivalent to this:
select *
from Items
where ID in l_Queue
Thanks,
Layne
Labels:
accomplish,
array,
associative,
binary_integerl_queue,
database,
declared,
index,
ltype_queue,
ltype_queuehow,
microsoft,
mysql,
number,
oracle,
server,
sql,
table,
thistype,
variable
Subscribe to:
Posts (Atom)