sql optimization webcast second part

NavStudent
Member Posts: 399
Ok saw the part.
Most of the topics have been discussed in here. So it was a good refersher. One thing that was mentioned in there was the tempbd purpose and that there isn't realy a good reason to put it on separate disk of raid1. That's because navision isn't creating any complex queries such as inner outer joines.
So my question is then
When you disable sift maintance on sql. Navision sums the actual table. Is this done in tempdb? If yes, would it make sense to have tempdb on separate disk?
My second question is
Is there any performance issues having mulitple test companies in production, even if they are used very seldom.
Most of the topics have been discussed in here. So it was a good refersher. One thing that was mentioned in there was the tempbd purpose and that there isn't realy a good reason to put it on separate disk of raid1. That's because navision isn't creating any complex queries such as inner outer joines.
So my question is then
When you disable sift maintance on sql. Navision sums the actual table. Is this done in tempdb? If yes, would it make sense to have tempdb on separate disk?
My second question is
Is there any performance issues having mulitple test companies in production, even if they are used very seldom.
my 2 cents
0
Comments
-
SIFT buckets are maintained on SQL Server in SIFT tables, one table for each NAV key that has sumindexfields. That's where the funky numbered tables come from. You find one that has tablename Cronus$32$1, that means it is a SIFT table for table number 32 in the Cronus company.
Take a look at the fields inside those tables (DO NOT MODIFY ANYTHING!!!!!!!!!). The 'f' fields are the fields included in the key, the 's' fields are the sumindexfields.
The 'buckets' are the SIFT levels that are maintained, which you can see when you open the table design in NAV and look at the key properties of a key that has sumindexfields.
Second question: Each NAV company has its own set of physical tables. Of course each additional database sucks system resources, but that is of course limited to the usage of that database. Do monitor it thoug, and make sure though that you don't interfere with the production system.0 -
[Topic moved from Navision to SQL Performance forum]0
-
There are SQL statements that you can use to measure the cost of every database file.
To be honest I do not know what they are. I always use the SQL Perform tools that have a built in function for this. :oops:
While analysing performance issues (which I do a lot) I can quickly see if other databases cause problems or if databasefiles are put on wrong disks.0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions