Yeah, we're definitely having performance problems at the moment.
But I don't understand why I'm seeing the "Columns With No Statistics" warning in the execution plan since I *just* did a UPDATE STATS on the entire database with FULLSCAN via a maintenance plan. I've never seen this warning...
Yes, that works... but interestingly, I was having the same syntax error with "UPDATE STATS", except in BOL it doesn't mention having to name the stats
My additional problem now is, in spite of the fact that I've created the stats for the table, I'm still getting a "Columns With No Statistics"...
Hi,
I have run create stats for a table in my database.
For example:
CREATE STATISTICS stats1
ON myTable(FundID) WITH FULLSCAN
(I also have a maintenance plan that updates stats with full scan for every table in the database)
However, I get warnings in my execution plan that this column...
Hi,
Keep getting this error msg:
Msg 156, Level 15, State 1, Line 1
Incorrect syntax near the keyword 'ON'.
Msg 319, Level 15, State 1, Line 1
Incorrect syntax near the keyword 'with'. If this statement is a common table expression or an xmlnamespaces clause, the previous statement must be...
I actually improved the query further by simply rearranging the order of the cols in the PK, additional index wasn't needed... also got rid of the lookup cuz the PK is a covering index
Hi,
Just wanting some opinions... is it better to eliminate an index SCAN (cost is 98%) with an [index SEEK (cost 15%) + key lookup (cost 15%)]? I accomplished this by adding a DESC index on one of the key lookup date fields.
Logical reads also went from 30000+ to 3 by adding the sorted index...
Right. I know this :-) That's why I was saying this is not a question of principles.
I just want to know if it's better to index based on # rows vs table size. In this case, I'm just indexing one DATETIME field.
This is a very specific thing I'm working on...
Hi,
When choosing which tables to index (by a DATE field in this case), is it better to select tables based on NUMBER of rows - OR - based on the total SIZE of the table? In this case, I'm not indexing all the tables, just ones most affected by size.
This is more a practical question as...
Ok, I see in BOL that "-q" does not exit the query, which would explain why it hangs...
But "-Q" says that it will execute the query and exit immediately... so how will the job step "know" if osql completed successfully? I would like the job step to fail if for some reason the osql query (sp)...
Hi Mr Denny,
This is the command I am running from a .cmd file, which is the last step of the job that is hanging:
osql -S MyOtherServer -d MyDatabase -E -q "Restore_DB_procedure 'MyDBToRestore', 'MyDBRestored', 'D:\MyBackupFile.BAK', 'D:\MSSQL.1\MSSQL\Data\'" -o D:\MyLogFile.log
-S...
The last step.
Everytime it gets to this step, the job just hangs, even though the restore is complete. It's a script that calls OSQL on another server... if that helps.
Thanks
Help. Does anyone know why a job would finish but still show as "executing" in the "Job Activity Monitor"?
The last step of the job is a "restore database" script I created. I see that the database has finished restoring as of 8:30 this morning, but it's now 11:30 and the job is still running...
Hi,
How can I get or simulate a query plan on a table-valued function?
I get this error:
Msg 2809, Level 18, State 1, Line 1
The request for procedure 'myFunction' failed because 'myFunction' is a table valued function object.
Thanks!
Hi,
I am using SSIS to run a stored proc. The results of the stored proc are then written to a file.
The problem I am having is that I can't figure out a way to get the column names into the file from the SSIS side (another issue).
So, I was thinking if I could write the query such that it...
Hello,
Is there a way to send a return value from a stored procedure (which is called from a job step) back to the job?
Basically, I want to be able to send a "failure" code back to the job from the stored procedure that will fail the job step.
Is this possible?
Thanks
But if the other drive, e.g. "x:" is just a logical partition of the same physical drive as "c:" then it really isn't a different drive, yes? And offers no additional benefit of protection.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.