SQL Server Read ismore

Question

SQL Server Read ismore

Viewing 15 posts - 16 through 30 (of 52 total)

You must be logged in to reply to this topic. Login to reply

Divine Flame SSCoach Points: 15943 More actions · Answer 1

yuvipoy (4/7/2014)
Those are the existing codes.
i need to modify them.
Yes using dead lock will lead to incorrect reports.

:hehe:

I am not sure if this syntax is supported yet:

SELECT * FROM TableName WITH (DEADLOCK)

Sujeet Singh

yuvipoy SSChampion Points: 10469 More actions · Answer 2

yuvipoy

SSChampion

Points: 10469

April 7, 2014 at 8:22 am

#1703804

Here is my table's sample data.

yuvipoy SSChampion Points: 10469 More actions · Answer 3

yuvipoy

SSChampion

Points: 10469

April 7, 2014 at 8:23 am

#1703806

Here is my tables sample data.

yuvipoy SSChampion Points: 10469 More actions · Answer 4

Divine Flame (4/7/2014)
I am not sure if this syntax is supported yet:
SELECT * FROM TableName WITH (DEADLOCK)

"DEADLOCK" is not a recognized table hints option in SQL Server.

So which database you are telling this hint?

Gail Shaw SSC Guru Points: 1004494 More actions · Answer 5

Lynn Pettis (4/7/2014)
yuvipoy (4/7/2014)
yes.
inorder to hide my business process i have renamed the column.
while pasting here i did not mention as b.column names for the columns.
For execution plan since it is having
Would help if you put data in your tables. Running the query against empty tables doesn't help us help you.

yuvipoy

Please, can you run the query against the actual production tables, take the resultant execution plan and do a find/replace over the XML to obfuscate the table names if necessary. Without the actual execution plan of the actual query which has the performance problem, we don't have a chance in hell of giving any useful assistance.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

yuvipoy SSChampion Points: 10469 More actions · Answer 6

Tab_tadata.txt and plan.sqlplan.sql files are the table insert scipt and execution plans.

Divine Flame SSCoach Points: 15943 More actions · Answer 7

yuvipoy (4/7/2014)
Divine Flame (4/7/2014)
I am not sure if this syntax is supported yet:
SELECT * FROM TableName WITH (DEADLOCK)
"DEADLOCK" is not a recognized table hints option in SQL Server.
So which database you are telling this hint?

I was actually refering to your this statement:

Yes using dead lock will lead to incorrect reports

But no issues ;-).

Sujeet Singh

yuvipoy SSChampion Points: 10469 More actions · Answer 8

Plase find tables.txt, plan.sqlplan.sql(executionplan), Tab_data.txt for inserting into tables.

Hoping this information will help me in resolve the issue.

Gail Shaw SSC Guru Points: 1004494 More actions · Answer 9

GilaMonster (4/7/2014)
Please, can you run the query against the actual production tables, take the resultant execution plan and do a find/replace over the XML to obfuscate the table names if necessary. Without the actual execution plan of the actual query which has the performance problem, we don't have a chance in hell of giving any useful assistance.

2 rows of data is completely inadequate to test performance on.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Lynn Pettis SSC Guru Points: 442447 More actions · Answer 10

yuvipoy (4/8/2014)
Plase find tables.txt, plan.sqlplan.sql(executionplan), Tab_data.txt for inserting into tables.
Hoping this information will help me in resolve the issue.

In addition to what Gail said, you have been around long enough to know that you need to provide the sample data in a readily consumable format, in other words as a series of INSERT INTO statements for the tables involved.

Also, the code you provided has some issues. One, it attempts to create a foreign key reference to TABLE4 which does not exist. Two, there are inconsistencies in the code that cause it to fail when run on a server/database using a case sensitive collation. If you define a column name as COL1 for example, you should consistently call that column COL1 through out your code regardless of the collation used on your server/database.

yuvipoy SSChampion Points: 10469 More actions · Answer 11

I have created insert script for tables.also added table4

is this sufficient

yuvipoy SSChampion Points: 10469 More actions · Answer 12

yuvipoy

SSChampion

Points: 10469

April 14, 2014 at 12:39 am

#1705637

is the information provided is sufficient

Gail Shaw SSC Guru Points: 1004494 More actions · Answer 13

Last try...

GilaMonster (4/7/2014)
Please, can you run the query against the actual production tables, take the resultant execution plan and do a find/replace over the XML to obfuscate the table names if necessary. Without the actual execution plan of the actual query which has the performance problem, we don't have a chance in hell of giving any useful assistance.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

yuvipoy SSChampion Points: 10469 More actions · Answer 14

this is the execution plan i renamed my original tables and columns.

Gail Shaw SSC Guru Points: 1004494 More actions · Answer 15

So the query, when run in production, returns 0 rows?

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass