SQL Performance — mibuso.com

NAV C/AL code vs NAV Query Object

jordi79 — Mon, 06 Jan 2020 05:08:57 +0000

Hi,

Version affected in NAV2017 cu 14.

Recently we hit a performance related issue. When I investigated further, I found out that this was caused by Query Objects in the Role Center. And when I tested, I even found out that it was better to use NAV C/AL to get the calculated results vs NAV Query object.

This is because, NAV Query object results are not cached. And the Role Center pages are updated every time user reverts to this page. So in a normal user usage, this page can be updated many times in 1 session. However, NAV C/AL results are cached. Therefore it is better to use NAV C/AL to retrieve results for Role Center pages and not queries.

You can read more in -->

https://docs.microsoft.com/en-us/dynamics-nav/query-objects-and-performance#differences-between-query-and-record-result-sets

My question is... in what circumstances would a NAV Query be better than using NAV c/al?

p/s Also, I would like to add that NAV standard role center uses NAV query objects.

Jordi

Business Central Benchmark

PJHa — Mon, 02 Dec 2019 16:23:45 +0000

Hello,

I test the validation of accounting ledger under Business Central.
I have an accounting sheet with 200,000 lines.

I would like to optimize my installation and validate as quickly as possible the volume of information
With a standard nav installation the system validates the sheet in 20 minutes
The processors do not exceed 20% load and the ram does not exceed 10GB used.

Is it possible to do better ?
Can you guide me on the different directions to follow ?

Thank you

Server App
Business CentralWave 2
No specific
VM Azure 32 cores
128 GB of ram

SQL Server
VM Azure 32 cores
128 GB of ram
TempDB 8 files
Ram minmum 64go on the basic engine

SQL Performance Query Object

byronic — Fri, 05 Feb 2021 12:05:29 +0000

Hello everyone!

We have a performance issue with a query object in NAV BC14.
We isolated the code snippet with the Performance Profiler that caused this issue and we stumbled upon a SQL statement (caused by an Query.READ) which needs 7-10 seconds to run through.

The SQL statement looks like this:

The code that calls the SQL statement is the marked line (StundentabelleAbwesenheiten is the query variable):

The query object that caused the problem looks like this:

We tried to create a new key in the table "DL Lohnzeile", but that had no effect on the duration time of the SQL statement:

What else could be the problem here?

Thank you very much in advance!

Heavy query with 2-Abort in profiler

Mkan1512 — Mon, 29 Mar 2021 11:18:08 +0000

Hi,

During a (re)search for a performance issue using the SQL Server Profiler we found (large) query's with an Error '2-Abort'.
Sometimes the reads are enormous (>200.000) and a duration of +73000
We see this query every time we open a sale/purchase order (or create a new) but not when we open a sale invoice (same table)

As a test, I removed almost all fields from page 42 (only No. and address info are still there) then we do not have the issue.
When I have only the No. field and "No. of Archived versions" (flowfield) we have the issue.

The start of the query is "SELECT TOP (50) ISNULL("Sales Header"."timestamp",0x0000000000000000) AS "timestamp",ISNULL("Sales Header"."Document Type",0) AS "Document Type",ISNULL("Sales Header"."No_",N'') AS "No_", ..."
It looks like that all the fields from table 36 are included.

Then there are several (7 for the sales order) OUTER APPLY (SELECT TOP(1) ... with an AS "SUB$No_ of Archived Versions" (for example)

Setup
The server (2012R2) is running on VMWare.
SQL (2012) & NAV (2013) are on the same server,
separate disk for Data/Log/TempDB
192Gb mem (174 for SQL)
Stats update every night

1. Error 2-Abort means that the client (not SQL) time-out. Why do we see this error (which time-out) ? How to fix
2. Is this query coming from the middle tier (I cannot find any code which is related) and is this normal behavior ?

Controlling VSIFT selection in BC

bbrown — Fri, 24 Jun 2022 19:57:50 +0000

I'm working on tweaking a process in BC18 (On premise). Part of the process uses a Query object that is summing "Warehouse Entry" records. I've isolated the issue to the VSIFT index it uses to calc that sum.

The 2 indexes of concern are Key5 and Key8. Both shown below. The process is summing "Qty. (Base)". The query is filtered on all the fields in key8. Unfortunately, all those fields are also included in Key5. So BC uses Key5. Not surprising, this is how VSIFT has worked for years.

If I drop the query into T-SQL and run it using Key8, the result is better than a 50% improvement. I'm looking for how I could get BC to use key8. In NAV, I could simply disable the SIFT maintenance on Key5 to accomplish this. Not an option with BC.

Any thoughts?

key(Key5; "Item No.", "Bin Code", "Location Code", "Variant Code", "Unit of Measure Code", "Lot No.", "Serial No.", "Entry Type", Dedicated, "Package No.")
{
SumIndexFields = "Qty. (Base)", Cubage, Weight, Quantity;
}

key(Key8; "Location Code", "Item No.", "Variant Code", "Zone Code", "Bin Code", "Lot No.")
{
SumIndexFields = "Qty. (Base)";
}

What is Smart SQL and does anyone have any documentation?

jackharris — Mon, 22 Aug 2022 15:26:10 +0000

I see that there's an option to disable it, but I wanted more info on what it was and whether there was any documentation that I could review with my team as to whether we should enable it for our clients?

Lock request timeout period exceedd Error 1222

srjohny — Fri, 24 Jan 2020 14:14:39 +0000

Hell everyone, My Sql is getting this error everyday, I'm using Navision BC , anyone can help with this? what could be the cause?

1 complex insert or multiple updates

ajayjain — Mon, 27 Feb 2017 17:42:19 +0000

Hi,

I need to consolidate G/L entry table for 16 companies
records are in millions
I have written Insert into Select query with lots of Join statement where I am calling G/L account name, etc from other tables into 1 new consolidated table

It works fine but to speed up
should I simply insert only g/l entry fields first and then update with g/l account name, dimensions,period etc
or
1 big insert will be better

Thanks

How can we measure the time consumption of the Code in SQL?

nav_student — Tue, 11 Jun 2019 07:30:06 +0000

According to the NAV TechDays 2018 - Performance: Business Central reloaded for the Cloud
https://youtube.com/watch?v=jGdkpTGmCgs

I saw that the guys were able to measure the time consumption of some pieces of code.

the simple question would be: How can I accomplish that? NAV, SQL, 3rd party software?

ISEMPTY create SQL query run over 10 sec, and keep happening. How to tuning up

tomguan — Fri, 29 Mar 2019 02:53:48 +0000

Recently our customer keep get table locking issue, and from NST event viewer, we found following information:
Message Threshold Trace Tag. Execution Time = 10010 milliseconds
Long Running SQL statement Task ID:3
SELECT TOP 1 NULL FROM "xxxxx_$Job" WITH(XLOCK) WHERE ("No_"=@0 AND "timestamp"=@1) OPTION(OPTIMIZE FOR UNKNOWN)

This query should just query job table to check if No. exist. (Not sure timestamp part), but run over 10 seconds. We are verifying with SQL team to see if they have reindex. Any other suggestion? Seems we got more and more this issue every few days.

Appreciate all help.

Thanks
tom

Query Store and NAV Performance

mcoscas — Wed, 13 Mar 2019 10:53:44 +0000

Hi everybody,

Does someone know if the activity of the Query store can cause performance problems in NAV 2017 ? Our customer is suffering from performance problems for a few weeks and we suspect that the query store is the origin of the problem...

Thanks in advance for your reply.
M.

RDP vs Client Performance NAV2009R2 with SQL

bertoos — Mon, 23 Apr 2012 09:14:56 +0000

Hi All,
I am by no means an expert in performance on NAV and SQL but I have been working with NAV long enough to have a “feel” for how it should perform.
We are encountering a very strange situation and I was wondering if someone can shed some light on this or have some experience in this.

When using Remote Desktop to the Server and performing 3 different tasks these are the speed results:
Action 1: 2 Seconds.
Action 2: 6 Seconds.
Action 3: 4 Seconds.

However, Connecting to the server via the client on the local machine and performing the same 3 actions, these are the results:
Action 1: 12 seconds.
Action 2: 92 seconds.
Action 3: 18 seconds.

It makes no difference selecting DEFAULT, TCP/IP, or Named Pipes from the client logon screen.
Network performance testing shows no issues and copying a 1 Gig file to the server from the client take as long as expected.
Any Ideas why this might be happening?

Some STATS:
Running NAV 2009 R2 Classic client (No 3tier)
Server is Windows 2008 latest service pack
SQL is SQL server 2008 (Latest service pack)
1Gigabit network

Looking forward to any ideas or suggestions.
Regards,
Bert

In one of our client is facing NAV Connectivity issues.

sangeetha1984 — Fri, 01 Mar 2019 06:49:25 +0000

For our Client they are facing NAV Connectivity issues - > Time Out or connecting error message will come, in Same NAV DB they have written SSRS Reports for internal day to day activity purpose. Client DBA is saying from SQL Log they are getting more thread for Single SPID. Please suggest any tool is there to drill down this ?

Query 1501 "Workflow Instance" Performance

bbrown — Wed, 19 Dec 2018 14:29:12 +0000

Has anyone had any experience (luck) improving the performance of Query object 1501 "Workflow Instance"? I'm working here with NAV 2016. As I investigate the performance of various processes I often find calls to this object account for a sizable portion of the processing time. This seems to be checking if a Workflow needs to be executed based on a table that has been updated.

The process I am focused on currently is a simple Excel import that loads a bunch of records into a General Journal batch. The calls to Query 1501 account for almost 40% of the processing time. Looking at the execution plan is SSMS suggested adding an index for "[Workflow Code]" to the [Workflow Step Instance] table. Along with several included columns. I tested that with and without the included columns. While it did improve the query when run in SSMS, it did not seem to have any noticeable improvement in NAV.

Improvement of this query would likely have a fairly global improvement on overall performance as it appears to get executed rather often.

SQL Server consumed very huge memory (90% plus)

julkifli33 — Tue, 28 Aug 2018 03:43:39 +0000

Hi All,
one of my customer has issue about SQL Server.
the server is only be used for NAV 2017, Jetreport and SQL Server 2014
they only use for 1 database with 20 users

the moment we restart SQL, memory consumed will lower down until 25%
once user login and used... it will raise significantly become 93-96%

by the way, the installed memory for this server is 24 GB.

is there a way we can solve this issue?
Thanks.

Index and statistic maintenance

Mauddib — Mon, 09 Jul 2018 09:01:06 +0000

We have been reviewing the default parameters of the scripts we use in SQL to rebuild and maintain indexes and statistics on the SQL side. A bit of a newbie to this I have a few small questions about the default values which are actually recommended by Microsoft for SQL server in general, but might be better modified for NAV specifically (Navision 2017 CU 2.1. SQL version 12.0.5579.0.).

The script does a reorganization if there is a 5 to 30% fragmentation and a rebuild for anything larger than this. Are there more recommended values for Navision than this? We find that we reach 5% remarkably quickly, in less than a week, in some cases.

Some of our indexes however are highly fragmented and remain so because the script only works with indexes larger than 1000 pages. Again, is there a more recommended value for Navision than this, or what is considered too high or too low.

How often is it recommended to update statistics on these indexes too? And what Fill factor is recommended for Navision? I have seen a few values recommended, but 5 or 10% free in a page is common as a recommendation.

Thanks muchly all

SQL Server 2012 EE - using NAV VSIFT Indexed View when that is slower than the Primary Key

CraigNeedham — Fri, 08 Jun 2018 12:10:05 +0000

Dear Experts

I have a very simple Query that selects records from a table where the timestamp (cast as a BigInt) is greater than a previously stored BigInt. It runs on SQL 2012 EE used to be quite fast (~100ms) and overnight slowed down (~5 Seconds). I looked at the execution plan and noticed it is using an Indexed View. I am not sure if it has always used the indexed view, but I suspect it swapped to using the indexed view and was using the primary key before. When I restructure the Query by swapping the cast, the query behaves differently on this server and uses the Primary Key and is quite fast.
There has been no Server configuration changes, Hardware or software changes and the data in the database is changing constantly.

My Question is: In what circumstances can SQL swap to using the Indexed View on EE when in fact the Primary key executes the query faster? The Query is very straight-forward:

SELECT DISTINCT cast(tab.[Document Type] as varchar)+','+tab.[Document No] AS RecID FROM [MyTableName] AS tab WHERE tab.[timestamp] > cast(cast(918273645 as bigint) as timestamp) AND (tab.[Document Type]=1)

I would really appreciate your insights into the inner workings of SQL Server 2012 Enterprise Edition, why would it all of a sudden execute the same code significantly slower than the day before...

Kind regards and thank you.

SQL Query on Enterprise Edition slowed down using the VSIFT indexed view.

CraigNeedham — Fri, 08 Jun 2018 11:58:20 +0000

New documentation on Monitoring Long Running SQL Queries using the Event Log

kennie — Mon, 04 Jun 2018 09:51:42 +0000

If you need to troubleshoot performance on Dynamics NAV 2017 or later:
https://docs.microsoft.com/en-us/dynamics-nav/monitoring-long-running-sql-queries-event-log

SQL Wait ASYNC_NETWORK_IO on NAV Production

sarma — Thu, 28 Sep 2017 16:10:39 +0000

Hi All,

While we are looking into NAV SQL Performance issue, we found that one of the top wait is "ASYNC_NETWORK_IO".As per my understading the NAV App server is not consuming the data generated by DB quickly.

Our Prod Setup is:

-2 Terminal services for NAV client, and they are load balanced.
-2 App Servers are load balanced
-1 DB server in AG group with Sync

Can someone help me how to trouble shoot this issue with NAV client? or some one come across this type of issue before.When i asked my Infrastructure team, they told me that every thing is fine, and nothing they suspect from NAV App server or Terminal server.

Is there any setting with in NAV defines Client memory size etc.? or is it down to NAV coding etc.?

Any help would be appreciate.

Regards
Sarma

SQL Profiler with NAV 2013 R2

bbrown — Wed, 17 Sep 2014 11:19:54 +0000

I find myself using SQL Profiler more often these days for a few reasons. Mainly looking into performance related issues. With prior versions, it was easy to separate the activity of different users as they each showed up as their own login. Being able to know who a SQL statement came from, let me hopefully sort of what they were doing and what area of the program needed to be looked at.

With NAV 2013 R2, the sessions all come from the same user. Mainly the login account for the NST. My question is there still a way to relate SQL Profiler activity to a specific user in NAV? Have I just been missing it?

Performance Issue when Running Report in Dynamics NAV 2013

dba_aku — Thu, 11 Jan 2018 11:54:47 +0000

We have an issue when Printing reports in RTC time to time. Reports get delayed in rendering and previewing output for some users. There are two different set of users connect NST using terminal server and direct RTC connections. Terminal Server users are not getting any issues while others are experiencing preview issues time to time. Sometime the client got stuck and could not close even. Dynamics NAV version is 2013.

How to Join [Active Session] tables with MSSQL SQL DB session

sarma — Tue, 26 Sep 2017 11:21:20 +0000

Hi All,

Can some one help me to Join Nav's [Active Session] table info with MSSQL DB level session.

Question:- how can i join below 2 queries

Example:-

Nav session:-

SELECT [timestamp]
,[Server Instance ID]
,[Session ID]
,[User SID]
,[Server Instance Name]
,[Server Computer Name]
,[User ID]
,[Client Type]
,[Client Computer Name]
,[Login Datetime]
,[Database Name]
FROM [dbo].[Active Session]

DB session:-

SELECT s.session_id, s.login_time, s.host_name, s.program_name,
s.login_name, s.nt_user_name, s.is_user_process,
database_id, DB_NAME(s.database_id) AS [database] -- return the ID & database name
FROM sys.dm_exec_sessions s
WHERE s.is_user_process = 1

Regards

New documentation on "Troubleshooting SQL Queries Generated by Dynamics NAV"

kennie — Mon, 22 May 2017 07:17:03 +0000

Hi,

We added new documentation on Troubleshooting SQL Queries Generated by Dynamics NAV:
https://blogs.msdn.microsoft.com/nav/2017/05/22/troubleshooting-sql-queries-generated-by-dynamics-nav/

Hope you can use it

Best wishes,
Kennie

NAV - SQL slow performance

Developer101 — Tue, 24 Jun 2014 14:42:19 +0000

The users are using a classic client customized form and perform queries on it.
This form is basically looking at two ledger entries tables. So when the users enter a value then it queries customer ledger table and other ledger table same time.

This is slow. There always been users performing queries on Customer ledger entries form directly to look for posted invoices etc. While there are other uses who post invoices. Is it fine to let the users query customer ledger entries form? Or there can be better way please help?

NAV 2013 R2 Performance on SQL Server 2012

navuser1 — Tue, 22 Nov 2016 11:57:49 +0000

Dear Sir,

The SQL Server is running on a well configured Server. The Server Configuration is given below.

1. OS - Windows Server 2012 R2
2. RAM - DDR3 24 GB ECC
3. RAID 10

The NAV SERVER is also installed in the same server. Almost 112 concurrent End-users are accessing the NAVISION Database thru different clients system.

I have noticed that in a particular time( 5PM/6PM) the SQL as well as the NAV SERVER are consuming the whole (20GB+) RAM of the Server everybody & makes the Server unstable.

So, please let me know how to solve this issue.

Thanks in adv.

Performance problem after hardware upgrade

krasich — Mon, 09 Nov 2015 11:35:01 +0000

Hi all

I have performance problem with classic client NAV 5.01
My new server use high performance storage, 5 time faster from old raid SATA drive.
When i operate with journals, reports , posting , general working with client, performance is the same as the old server.
Where to look for the problems? SQL server or database ?

Thank you !

Question about PAGEIOLATCH wait type

melsadek — Fri, 18 Nov 2016 22:01:18 +0000

Calling all SQL Performance Experts! If you want a challenge, this is it! This is a LONG read, but I believe you should have everything you need to provide recommendations. The TL;DR version is at the bottom.

I have a 24/7 manufacturing customer that has recently started to experience massive/crippling locking timeouts + horrendous posting times. I'll setup the scenario for all to see, and then I'll discuss the details:

- NAV 2009 R2 Classic with SQL Option
- SQL Server 2008 R2, Version 10.50.2500.0. 32GB RAM allocated to SQL Server.
- Fully VMware environment. 1 server for NAV DB on SQL, 1 server for RDP.
- 23 concurrent users. 50% through RPD login, 50% through local clients.
- Database is about 500 GB on Drive D, with 20% free space. Log file is always truncated on Drive E.
- Only one TempDB database exists, and is also on Drive D.
- RAID 10 configuration, 5400RPM drives.
- Regarding Fragmentation: The highest fragmented index larger than 100 MB is Item Ledger Entry$16, at 18.5%
- Largest tables: GL Entry: 61GB, Value Entry: 54GB, Prod. Order Comp.: 27GB, Prod. Order Routing Line: 24GB, Item Ledger Entry: 17GB. Then a huge drop-off in sizes.

So now the scenario:

Cost adjustment is scheduled to be run every weekend at specific known times. During those times, users are aware that they cannot ship/invoice anything, nor can they post journals, because of the severe likelihood they'll be locked out by the cost adjustment process. Once cost adjustment is finished/stopped, a scheduled routine that posts all "declared" consumption and finished goods populates the consumption and output journals and then proceeds to post them. Over time, this auto-posting routine has gotten slower and slower, to the point where now it *may* post one journal line per second. This posting performance is steady throughout the week, but more pronounced after cost adjustment since the auto-posting at that point needs to catch up over the many hours it hasn't run while cost adjustment was running (we use the NAS for scheduled jobs).

While the production floor can safely "declare" their finished products without locking, just this week they started receiving locking timeouts on the Serial No. Info. table while the auto-posting routine was happening. This is unusual and critical because it prevents finished goods from being on hand.

So this is a MAJOR show-stopper issue. I did some digging into it and I found out that while the auto-posting routine is running, it is frequently flagged with a PAGEIOLATCH wait type in SQL. Checking the Resource Monitor, this wait type is corresponding in MASSIVE data read surges with little to no write activity on the DB NDF file. We're talking about reading 20MB/sec for several minutes if not hours in a row. So while this PAGEIOLATCH is being flagged on BOTH cost adjustment and auto-posting routines, other users on the production floor are being blocked by the former processes through a LCK_M_U wait type. This locking wait type is occurring on several tables, but primarily the Serial No. Info table (as explained above).

After some digging I settled on the DBCC TRACEON(1224) flag recommendation by Jorg, since it was not enabled. This IMMEDIATELY solved the problem and we do not receive any more locking errors on the Serial No. Info table.

However, crappy DB performance still remains. As I'm writing this I'm looking at the Resource monitor, and I see high read I/O but almost 0% CPU activity on NASSQL.exe and SQLSERVER.exe. And this...goes on and on for hours, until suddenly the Read I/Os drop down to almost zero, and then database gets into a rhythm of writing about 30KB/sec to the LDF and NDF files, while NASSQL.exe and SQLSERVER.exe are between 5-20% CPU utilization.

We're coming up on year-end and we haven't ran a full cost adjustment in 3 weeks due to lack of time and the locking timeouts mentioned above. Above all, right now we're trying to make sure there are no bottlenecks in our processing, but I keep seeing the Disk I/O as the biggest problem. I have repeatedly told the customer we need to upgrade their Disks, which are more than 5 years old, as well as to do full index rebuilding on their primary tables (GLE, VE, ILE, IAE), but the customer shot it down because putting the production floor on hold is not an option. So between now and the Christmas break there may not be a single down day, including the Christmas break (they work through all holidays!).

At this point I'm at a loss of what to do to make auto-posting faster. I've tried everything I can think of, except of course doing hardware upgrades and rebuilding indexes (as I said, customer can't have downtime). I need suggestions on what I can consider now, or if anyone can guide me to the true source of this problem.

TL;DR version: Are there any NAV/SQL performance consultants in the Greater Toronto Area that want to come onboard and help solve this problem?

Compatibility Level 120 -> Lock and Speed issues

kball — Mon, 06 Feb 2017 08:16:18 +0000

Hello all,

we have recently upgraded from NAV 2009 R2 to NAV 2016. We are using SQL 2014 as database.
On NAV 2009 the compatibility level of the database was 100 (SQL 2008 R2). When we upgraded to 2016 we used compatibility level 120 (SQL 2014) for the new database.

We have experienced many issues with performance and locks on the database.
This not only happens when we are using certain reports in NAV, it also happens when we connect to the database via ODBC.

Let me give you two scenarios we are using:
1.) Connecting via ODBC:
We are connecting via ODBC to the database to make queries (sometimes via MS Access, other times via BI-Tool). Of course we are using read only to make to queries. There are certain queries which run for some minutes. We can now see on the SQL server that this causes different types of locks. Most times we see LCK_M_X and LCK_M_U locks. This causes the NAV client to freeze for all users until the query is finished.

2.) Reports in NAV
We have a report in NAV which deletes contacts. In NAV 2016 we have experienced big issues in the runtime and many locks as well. In NAV 2016 it deletes a staggering amount of one contact per minute and the runtime causes the database to be locked big time. In 2009 we were able to run this report during the working day and we did not have any locks, because the time to delete a contact was short enough.

Together with my NAV partner we have searched for an answer for many hours and by accident we have found a solution.
We have changed the compatibility level back to 100 (SQL 2008 R2). We could see immediately that we have no issue anymore.
Both of the scenarios i have described run fast and without any locks now.

This helps us and our users, but we do not understand this at all.
Did anyone of you experience anything like this or does anybody have an explaination on the reason of this strange behaviour?

Upgrading from 2009R2 to 2013 taking a LONG time

Charleh — Fri, 04 Oct 2013 09:28:13 +0000

I've already posted on the Three Tier forum and someone suggest I repost here, so apologies for any duplication:

viewtopic.php?f=32&t=59121&start=0

To summarise the issue I'm having, I'm trying to upgrade a NAV2009R2 database to 2013, but at the point of doing the Ledger Entry Dimension upgrade, the UI freezes up (obviously it's busy) and SQL/CPU is being hammered. The problem I have is that I think nothing is actually wrong, but that due to there being over 68 million dimensions in the table there is a lot of processing to be done.

I've run this for a couple of days on a pretty decent machine and with no joy (I had to shut the machine down in the end as it's my work laptop - the development server we have is actually lower spec than my dev laptop)

Does anyone know how long this should take? Is there any good way of speeding the process up? I don't have a lot of time to investigate at this moment so I've not looked at the execution plan in great detail, but I can see that it doesn't seem complicated and there don't appear to be any unnecessary scans - all the work is in clustered index seeks

I'll drop the details from my previous posts here too:

I've put the DB in simple recovery model and expanded the size of the database to be twice that of the original data (the size is now over 100GB) - is this a normal amount of time to wait before 1% on an upgrade of this size? I've already moved the data from NAV4 to NAV2009R2 which only took a couple of hours. I need to take into account the time to upgrade to 2013 when planning the production database upgrade - and having the upgrade take more than two days is going to cause all sorts of problems for the client (ideally I'd like to get it done in a day!)

I'm running everything locally - the machine that is running this processed a v400 to 2009R2 update in a matter of minutes for the 50gig db (it took a few minutes for upgrade step 1 for the biggest company and less than an hour to finish the second upgrade step)

My company database/tempdb are not growing and the machine performance is as so:

30-35% cpu usage (most of that is SQL server)
at points 100% disk utilisation, at the moment not much
almost 100% ram utilisation

I'm on decent machine running 2 quad core i7s and an SSD - 16gig of ram, and like I said - the first upgrade took no time at all.

I've left this running all day and overnight and it's still on the 'preparing for upgrade' stage (0% progress)

Checking SQL shows the following UPDATE statement is running:

Code: Select all

update [Company Database$upgrade355_Dim] set DimSetID= (select DimSetID from [Company Database$upgrade355_DimSetID] as D where ((D.DimVal1 = [Company Database$upgrade355_Dim].DimVal1) or (D.DimVal1 is null) and ([Company Database$upgrade355_Dim].DimVal1 is null)) and ((D.DimVal2 = [Company Database$upgrade355_Dim].DimVal2) or (D.DimVal2 is null) and ([Company Database$upgrade355_Dim].DimVal2 is null)) and ((D.DimVal3 = ... etc

There don't appear to be any resource waits - I've run the query that SQL management studio runs to get a list of locks for process monitor, and the only entry is:

DB: Company Database
Status: RUNNING
Cmd: UPDATE
App: .Net SqlClient Data Provider
CPU: 290888
I/O (MB): 106
Last Req: 2013-10-01 21:27:08.693

So as far as I can see, SQL is actually just processing.

Checking the stats for IO I get

CPU ms/sec: 949
L. Writes/sec: 2
L. Reads/sec: 831404

Execution plan says that the heavy hitting operation is a key lookup against a clustered index which says it estimates at 80 million executions - this is taking up 79% of the query cost

- in summary, it looks like SQL is doing something, but it's been doing this for hours and hours - is there anything I can do to speed this up?