Few things I am curious about:
1. Always rowlock: I see people say if you turn that on it will use A LOT of memory. What is A LOT? I have 16GB on the server with 14GB allocated to the server (Navision 4.00SP3 with a DB of 10-20Gb for now but will surely go soon to 100GB + ).
2. Sift levels. Let's say I have 2 keys (simplified example):
- Customer No., Customer PO No.
- Customer No., Posting Date
both with SIFT on Amount. We set maintain SIFT levels to both levels: Customer No. and Customer No., Customer PO No. / Posting Date.
That means in theory I would have the Customer No. sift level twice (I know it is 2 different tables in SQL). If I disabled the Customer No. level on second key when I use that second key in code and do a calcsums on Amount with Customer No. filter only would Navision use the SIFT level from first key or just do an actual table sum? (Hope that made some sense)
3. I heard that putting the SIFT tables on it own disk array helps. Is that true?
Apathy is on the rise but nobody seems to care.
0
Comments
"My two Cents":
1) "Always Rowlock" adds the Query Hint ROWLOCK to the statement, which means that row-locking is enforced, lock escalation is prevented.
But usually you want to have lock escalation, e.g. as it is faster to maintain a single range lock instead of thousands of row locks. Of course, the higher the locking level, the higher is the risk of getting conflicts with other processes.
One big misunderstanding is, that without "Always Rowlock" the SQL Server does not perform row-locking. This is non-sense, SQL Server always starts locking on the lowest level possible (usually the row-level), and then could escalate.
I recommend to disable this setting. If you then encounter blocking problems, these usually could be solved in a different way.
Have in mind, that each lock has to be administered in the master db. "Always Rowlock" could generate quite a lot of "traffic" for the master db; and it's getting worse, if the master db e.g. is stored on slow drive C:\ or something ...
2) Check this out: http://www.mibuso.com/forum/viewtopic.php?t=18933
3) Sure it helps. Storing SIFT tables separately means to have a dedicated filgroup for them. Hence, SQL Server could process this file with another Thread, speeding up processing (if enough CPU power is available). If further this file is stored on a dedicated dphysical disk, you benefit from the dedicated I/O as well.
This is an advice from the "NAV Hardware Sizing Guide". Unfortunately it does not say how to implement this :evil:
Well, it's tricky business, first you have to rename all original SIFT tables, then re-create them - original name - in the new filegroup. Then copy the data from the old SIFT tables into the new ones (Same procedure when partitioning tables). Sounds simple, but requires some smart TSQL scripting ... or has anybody an easier way for this task? Maybe some utility? Hmm, maybe I'll try to generate one :idea:
Best regards,
Jörg
NAV/SQL Performance Optimization & Troubleshooting
STRYK System Improvement
The Blog - The Book - The Tool
NAV/SQL Performance Optimization & Troubleshooting
STRYK System Improvement
The Blog - The Book - The Tool
1) I know that SQL starts with row lock. It is just that I would love to have it always rowlocking. I have a rather large Sales Line table and about half of the company changing it 20K lines at a time ... Soo among other things was wondering if that would have helped.
In a way rowlocking is really not important if that hint does not carry over to the SIFT tables since that effectively pretty much makes it table lock.
2) I read the thread but still don't feel answers my question.
3) Keep me posted if you get a script. I thought you would be able to do it from the Management Studio.
- Customer No., Customer PO No.
- Customer No., Posting Date
If you follow the principle to only enable the pre-last bucket - the first level in aggregation - all higher levels e.g. "Customer No." could be calculated from them. In this case it does not matter which SIFT table C/SIDE uses.
Script is coming soon. Of course you could do everything with Mgmt.Studio, but that would be quite annoying to fiddle with dozens of SIFT tables manually ...
NAV/SQL Performance Optimization & Troubleshooting
STRYK System Improvement
The Blog - The Book - The Tool
By default sql server will row lock, it will choose page locks if it is better. The cost relates to the number of locks required, each requires the same amount of memory, so if the table ( or index ) is narrow and you want to lock 20k rows - 20k locks - if there are 10 rows per page then it will only require 2k page locks. At certain points sql server may escalate to an extent lock, 8 pages, generally if you select locks for greater than 50% of the table then it will excalate to a table lock, or before if resource is low.
If your row size is over 4k then a page lock will equal a row lock, you can also juggle rows to pages through fillfactor and padding. Note that using high fill factors may well force lock escalation by requiring a greater number of locks for a range update. The whole process of locks vs resource is quite complex and trying to outhink ( or tell sql server you know better on how to execute commands ) may well lead to big performance problems.
Version: 0.90 - BETA - SQL Server 2005
No guarantee, no warranty, no support - use at own risk, blame someone else.
Installation:
Copy the following Code as new query to Management Studio and execute it within context of your NAV database:
Syntax:
@filegroup specifies the filgroup to which to move the SIFT tables; thus it must exists (to be created manually ahead)
script specifies whether to generate a TSQL script for movement; 0 = NO = instant execution; 1 = YES = TSQL (default). It's recommended to use the scripting option to check the output.
Example:
This will generate a TSQL script executing these statements:
So, what is does is this:
1. Drop the CLustered Index/PK constraint and move the leaf nodes - the table - to the new filegroup
2. Re-Create the PK/CI constraint in new filegroup
3. Re-Create all Non-Clustered indexes in new filegroup (includes standard NCI and cusomized ones, e.g. if the SIFT table was pre-tuned; INCLUDES supported)
Again, this is considered a BETA version as it is just briefly tested :bug:
I would appreciate to get your comments, test-results and enhancements.
Once it has been approved I'll put it to the download section.
Have fun!
NAV/SQL Performance Optimization & Troubleshooting
STRYK System Improvement
The Blog - The Book - The Tool