Viewing 15 posts - 14,221 through 14,235 (of 49,552 total)
Include columns are stored in the pages at the leaf level of the nonclustered index. Hence if you are looking at a leaf level page of an index that has...
February 18, 2013 at 3:52 pm
When the number of pages is low, you probably don't want to worry about fragmentation. Besides, you can't defragment a 1 page index.
February 18, 2013 at 7:56 am
dsachu (2/18/2013)
So, would request you please suggest me why sql is not fragment as per my understanding........because I have read some article.
Because the table's far too small for you to...
February 18, 2013 at 7:26 am
Performance, no. Readability and ease of coding, yes.
February 18, 2013 at 7:24 am
Row by row better? Well, in the sense that if one fails the whole batch won't fail, but then you have no guarantee that all the contacts were updated.
A single-row...
February 18, 2013 at 6:08 am
Batch - faster, less resources, consistency at a statement level
Row by row - slow, more locks, no automatic consistency, you need to use transactions (if one update fails, the rest...
February 18, 2013 at 5:48 am
Bhuvnesh (2/18/2013)
GilaMonster (2/15/2013)
identity column does not guarantee uniqueness.is it so ? but it always generate new value incremented to previous one
Yes, it is so.
An identity will, by itself...
February 18, 2013 at 5:37 am
How big is the table? How many pages?
February 18, 2013 at 5:36 am
While this will work, it is not a recommended configuration.
Two reasons.
- You can only restore WITH NORECOVERY, hence you can't use the logshipping secondary for reporting
- If you ever...
February 18, 2013 at 2:32 am
Possibility 1: They're tiny tables or heaps. Small tables you don't need to worry about, heaps need a different command to rebuild (and besides, fragmentation means a different thing for...
February 18, 2013 at 2:28 am
Not just time, all performance characteristics. You need to have a baseline before you start tuning, or how do you know whether your work has been effective or not?
February 17, 2013 at 2:25 pm
Measure query performance before you create the index. Record the stats (and you should have some idea what queries you're tuning)
Add the index
Measure query performance again.
Compare.
February 17, 2013 at 9:08 am
Create the index, run your benchmark (the one you set up starting any tuning work), see if there's an improvement in performance.
As for why not on a production server, load,...
February 17, 2013 at 4:24 am
Test the indexes out, one by one. If they help performance keep them. If they don't, drop the index and ignore the recommendation.
Never run DTA on a production server.
February 17, 2013 at 3:30 am
Restarting SQL while a process is rolling back (as it would have been after running out of log space) is indeed a bad idea as the rollback then has to...
February 17, 2013 at 3:26 am
Viewing 15 posts - 14,221 through 14,235 (of 49,552 total)