Showing posts with label series. Show all posts
Showing posts with label series. Show all posts

Monday, March 26, 2012

Index Question

I have a series of many-to-many relationships, so obviously have a number of
'join' tables. These join tables store only the unique key from the other
tables.
Is there any advantage to indexing the fields in the join tables or is it
not necessary because the data in them is technically indexed in another
table or do they still need indexing in their own right?
Thanks
Keith
It is always good practice to create an index on foreign key column as the
linking column
( I assume you have pimary key with clustered index)
An index on a foreign key column can substantially boost the performance of
many joins.
"Keith" <@..> wrote in message news:O1DllPVSEHA.2408@.tk2msftngp13.phx.gbl...
> I have a series of many-to-many relationships, so obviously have a number
of
> 'join' tables. These join tables store only the unique key from the other
> tables.
> Is there any advantage to indexing the fields in the join tables or is it
> not necessary because the data in them is technically indexed in another
> table or do they still need indexing in their own right?
> Thanks
>

Friday, March 23, 2012

Index Question

I have a series of many-to-many relationships, so obviously have a number of
'join' tables. These join tables store only the unique key from the other
tables.
Is there any advantage to indexing the fields in the join tables or is it
not necessary because the data in them is technically indexed in another
table or do they still need indexing in their own right?
ThanksKeith
It is always good practice to create an index on foreign key column as the
linking column
( I assume you have pimary key with clustered index)
An index on a foreign key column can substantially boost the performance of
many joins.
"Keith" <@..> wrote in message news:O1DllPVSEHA.2408@.tk2msftngp13.phx.gbl...
> I have a series of many-to-many relationships, so obviously have a number
of
> 'join' tables. These join tables store only the unique key from the other
> tables.
> Is there any advantage to indexing the fields in the join tables or is it
> not necessary because the data in them is technically indexed in another
> table or do they still need indexing in their own right?
> Thanks
>

Index Question

I have a series of many-to-many relationships, so obviously have a number of
'join' tables. These join tables store only the unique key from the other
tables.
Is there any advantage to indexing the fields in the join tables or is it
not necessary because the data in them is technically indexed in another
table or do they still need indexing in their own right?
ThanksKeith
It is always good practice to create an index on foreign key column as the
linking column
( I assume you have pimary key with clustered index)
An index on a foreign key column can substantially boost the performance of
many joins.
"Keith" <@..> wrote in message news:O1DllPVSEHA.2408@.tk2msftngp13.phx.gbl...
> I have a series of many-to-many relationships, so obviously have a number
of
> 'join' tables. These join tables store only the unique key from the other
> tables.
> Is there any advantage to indexing the fields in the join tables or is it
> not necessary because the data in them is technically indexed in another
> table or do they still need indexing in their own right?
> Thanks
>

Friday, February 24, 2012

Index corruption

Hi all.
I've got a database that people are posting data to
through the index. The other day, someone posted a
series of records and called a select statment from the
index to check their work. When they did, three entries
were missing. I went back and found that the data was on
the disks and could be regenerated by recreating the
index tables.
Now I'm trying to figure out why this happened and
whether I can expect that it will happen again. I
restored the last .bak file prior to the incident and
walked through the transaction logs up to the event,
running checkdb with each. The first trans log after the
event reported that it could not be restored due to an ID
being newer on the previous trans log.
I've now restored the first .bak file after the incident
and run checkdb. I'm getting this error:
Server: Msg 8929, Level 16, State 1, Line 1
Object ID 1541580530: Errors found in text ID 25723928576
owned by data record identified by RID = (1:171739:3) id
= 390945.
If I do a select statement for this ID, I get:
Server: Msg 601, Level 12, State 3, Line 1
Could not continue scan with NOLOCK due to data movement.
Does anyone have an ideas for why this happened? Other
actions I should try? Or the likelihood that this will
happen again?
Thanks greatly,
~BrendaHi Brenda,
From you description, it seems that you have resolved this problem and you
want to point out what induce this issue. If I have misunderstood, please
feel free to let me know.
Could you also send me the following logs/files so I can perform a more
analysis of what is happening:
1. SQLDiag.txt from the SQL Server 2000. To generate this file you need to
use the command line utility SQLDiag.exe -I instance_name . For more
information about the utility check SQL Books On-Line article "sqldiag
Utility"
2. System and application event logs saved as text files. To do that in
Windows NT
4.0 Event Viewer go to Log menu, choose Save As. From "Save As Type" dialog
box choose Text Files (*.TXT).
3. Any previous reports/output files of Maintenance Plan like the one you
have already attached.
4. Any DBCC CHECKDB results if you have run those manually, outside the
Maintenance Plan.
I am standing by for your response.
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.