Viewing 15 posts - 20,296 through 20,310 (of 22,219 total)
Flush the procedure cache, dbcc freeproccache(), and then rerun the queries. I think MANU might have it. You inserted one table from the other. It's indexes are going to be...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 30, 2008 at 6:12 am
I would definitely start with the trace to see which procedures are running long because I'll bet they're the same ones that are causing this problem. There are some great...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 30, 2008 at 6:08 am
Blocking will require more than perfmon & profiler. Do a search in the scripts and you'll find some timed scripts that will gather that data for you.
SQL Server 2008 is...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 30, 2008 at 6:01 am
Since you're already joining to the table, why not use the FREETEXT in the WHERE clause instead of joining the table to itself?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 30, 2008 at 5:59 am
Whoops. I'm a moron.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 30, 2008 at 5:56 am
Get the execution plan and it will tell you exactly what's occurring when. That's what they do.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 30, 2008 at 5:52 am
You're pretty close
But, am I supposed to drop the foreign key from the other tables that use this pk as a fk ?
Yes, you need to drop the foreign key...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 30, 2008 at 5:50 am
sherlockian21 (5/30/2008)
Select *
from
(
select (top 500 row_number() OVER (ORDER BY(rank desc) as resnum, rank, description, table2.col, table3.col, table4.col
from table1 inner...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 30, 2008 at 5:43 am
To determine what the queries are doing your friend needs to look at the execution plans. That will identify where the time is being spent and suggest possible solutions.
Also, I...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 29, 2008 at 11:52 am
So, if I understand this correctly, the plan is to break down a title into it's component words, store each word in seperate table with a link back the title...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 29, 2008 at 10:20 am
OK. Run Profiler. Be sure you have one of your ADO connections on line. You can just use the defaults. Check the connection settings of the ADO connections. I'll be...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 29, 2008 at 9:13 am
So the query would run fine in SSMS, but when run from VB it times out?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 29, 2008 at 8:46 am
If he already has a design that has 1.2 million rows and he's "considering indexing" then he's way behind the eight-ball already. I'd suggest focusing on one thing, clustered indexes....
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 29, 2008 at 8:26 am
The first thing that comes to mind... Have you updated the statistics and/or rebuilt the indexes after moving the data from 7 to 2005? It's my understanding that this is...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 29, 2008 at 6:00 am
Everyone else has nailed it. The one other thing you might consider is using NVARCHAR(MAX) if you are potentially storing more than 50 characters. Well, more than 4000 in this...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 29, 2008 at 5:56 am
Viewing 15 posts - 20,296 through 20,310 (of 22,219 total)