Addicted2AX / Addicted2SQL - SQL Server

Dynamics AX 2012 & SQL Server 2008R2: Cross Join vs. Inner Join – Houston we have NO Problem

nospam@example.com (Addicted2AX) — Tue, 13 Mar 2012 21:48:19 +0100

Recently I had to bulid a rather complex list page. The Dynamics AX 2012-query contained some INNER JOINS and some OUTER JOINS between tables. After finishing designing the list page the performance when running the list page was suboptimal.

After adding some indexes performance increased drastic but still had some room for improvement.

So I ran an SQL Server Profiler Trace and was a little bit shocked for a moment: The SQL statement which was created Dynamics AX 2012 to be send to SQL Server 2008 R2 was a CROSS JOIN with a WHERE-clause and not an INNER JOIN.

First thought was that I remembered that a CROSS JOIN creates a cartesian product of both tables. Cartesian product means that every of the first table is joined with every row of the second table. Then I remebered that a CROSS JOIN with a WHERE-clause delivers in the end the same result as an INNER JOIN.
Second though was that in other RDBMS and older versions of SQL Server even when the result is the same like in an INNER JOIN a CROSS JOIN with a WHERE-Clause may perform not as good as an INNER JOIN.

So my idea was to check if there is maybe a performance problem in Dynamics AX 2012 by using CROSS JOINS instead of using INNER JOINS.
Firstly I bulid a query using SalesTable-table joined with SalesLine-table using an INNER JOIN as join mode and as fetch mode “1:n”. I have also tested “1:1”. Ressults were identically.

For test purposes I used „forced Literals“ and the following SQL Statement was send to SQL Server by Dynamics AX 2012

Execution Plan looks quite good: For both tables a „Clustered Index Seek“ was performed. Then both result sets were joined. Finished. Looks quite good to me.

Let’s see what statistics say:

434 logical reads for SalesLine-table and 163 logical reads for SalesTable. CPU-time used: 47ms. Total elapsed time: round about 2 seconds.
Not bad, but maybe an INNER JOIN performs even better.

The following SQL statement using an INNER JOIN was built by me in the way how I would have built it if I was Dynamics AX 2012.

I must confess that I was a little bit surprised that both Execution Plans were identically.

Checking statistics shows the same result: Same numbers of reads for SalesTable-table and SalesLine-table. Differences in CPU-time and in total elapsed time are inside normal fluctuations when running SQL Server. So needed time when running a CROSS JOIN with a WHERE-clause and time needed when running an INNER JOIN can said to be identically.

A short Google-search showed the following result. Last version of SQL Server which seemed to perform a CROSS JOIN with a WHERE-clause worse than an INNER JOIN was SQL Server 2000. Since SQL Server 2005 query optimizer treats a CROSS JOIN with a WHERE-clause identically to an INNER JOIN.

Update 22.03.2012:
I faced a (minor) problem with a CROSS JOIN with WHERE-clause: I joined two tables in a larger query by using Expression “Relation” with value “Yes” (by setting Expression “Relation” to “Yes” relations are set automatically using the relations specified in Relations-knot of the specific table).

Even so the relation seemed to be set correctly in Dynamics AX 2012 the SQL Statement generated by Dynamics AX 2012 was not generated correctly: Only a CROSS JOIN without a WHERE-clause was generated. So the CROSS JOIN generated a cartesian product with a large amount of data.
Fastest and proper working solution I found was setting back “Relation” to “No” and rebuilding the relation manually. Manually generated relation has exactly the same values as the automatically generation.

This seems NOT to be a general problem, because the other automatically generated relations between the tables of the query work proper and without any problem. I also had no problem using Expression “Relation” with value “Yes” with other queries.

Conclusion:
When Dynamics AX 2012 generates a CROSS JOIN with a WHERE-clause instead of an INNER JOIN when performing an INNER JOIN: There is no performance gap.
If you have any with unexpected result sets which may look like a cartesian product check the relations between the tables, kill the existing automatically build relations and rebuild these relations manually.

SQL Server performance-tuning with Instant File Initialization

nospam@example.com (Addicted2AX) — Wed, 09 Nov 2011 20:51:08 +0100

In fact I was writing a checklist on the topic SQL Server performance tuning with focus on running the Dynamics AX 2012 databases.
One tip deals with “Instant File Initialization”. Even though there are some articles in the internet about this feature, I have not really found detailed “official” information of Microsoft.
The questions are: What is Instant File Initialization? How can Instant File Initialization be started? What are its limits? Are the risks?

1. Instant File Initialization: theory and practice
Standard behavior of SQL Server when
a. Creating a new Database
b. Adding a file to a database
c. File growth (manual and auto-growth)
d. Restore of database (if it includes database-creation or file growth)
is that the new allocated space is overwritten by zeros before it can be used by SQL Server.

I have made some tests with a 32bit Developer Edition of SQL Server 2008 R2 on my Intel Core i3 (2x2,13 GHz; 3.2 GB of usable RAM; 2,5 inch notebook-hard disc) Laptop. Results for 64bit systems are comparable. Of course other hardware affects the results in detail.

The results:
Without enabled Instant File Initialization the creation of a new database with a size of 10 GB took about 4:30 minutes. Raising the database size to 20GB took another 4:30 minutes.

Blocking a productive system for such a period of time can cause some trouble with users and your boss.
Those are scenarios where Instant File Initialization can help you.

After setting up Instant File Initialization SQL does not overwrite newly allocated space with zeros any longer: Creation of a database with the size of 10GB just took round about 5 seconds. Raising the database size to 20GB took somewhat between 5 and 10 seconds. On a fast server-system with SAN-storage this time span should be even shorter.

2. Setting up Instant File Initialization:
Instant File Initialization is not mainly a SQL Server feature. It is an operating system privilege which was established by Microsoft with Windows Server 2003 and Windows XP. Therefore it is also available with Windows Vista, Windows Server 2008 and Windows 7.

To set up Instant File Initialization you have to grant the service account which is running SQL Server the SE_MANAGE_VOLUME_NAME-privilege. To get this privilege add the SQL Server service account to Perform Volume Maintenance Tasks security policy. Quite simple, isn’t it?

Please note: Just the Professional versions of Windows Vista and Windows Server grand direct access to the group policies. Home Premium versions have not installed the needed tools to edit the polies directly. In these versions you have to edit registry directly.

3. What tasks do not profit of Instant File Initialization?
Instant File Initialization does not work with log files. When allocating new space for log files SQL Server is zeroing out the needed space even though Instant File Initialization is enabled.
According to Paul S. Randal log-files needed to be zeroed out because this is the only way to determine the end of the log-file in case of a crash. For more information read his blog-entry.

4. Are there risks?
According to some Microsoft blog-entries there seems to be a slight risk. If you are running two or more instances of SQL Server on a computer there could be the risk, that space which was formally allocated to one instance, will be allocated to another instance. With enabled Instant File Initialization this space is not overwritten with zeros. Therefore there is the risk that users of this other instance can read old data of the instance which had formally allocated the space.
I have spoken to a Microsoft Consultant about this risk. He said, that the risk is mainly of a theoretical nature, because the data extremely hard to read and most time not of a specific order.

5. Conclusion:
Instant File Initialization can speed up creation of big, new databases or raising the size of an existing database in a significantly.
Log-flies are not affected by Instant File Initialization, because allocated space of log files needs to be zeroed out by design.
There is a slight security risk when you run more than one instance of SQL Server but when you can rule out this risc for your data Instant File Initialization is a great feature which can speed up SQL Server significantly.

Problems with SSRS & pdf-export after subsequent installation of fonts

nospam@example.com (Addicted2AX) — Wed, 19 Oct 2011 19:13:09 +0200

Today I had to do a subsequent installation of some fonts that were not available on SSRS server after initial installation.

Even though the new fonts were available in Notepad and also worked fine with it, I had some trouble to make the fonts work with reporting services and in reports exported into a pdf-document.

After checking the pdf-document report-layout was totally broken. The reason for that problem was simple: Not the subsequently installed and in the report used font was utilized but another (randomly chosen?) windows font, although the newly installed font was correctly embedded into the pdf-document.

I have restarted the SSRS-services but the problem continued.
Long story short: I had to reboot the complete Server. After the reboot the problem was gone.

Maybe an obvious solution but the problem was that a lot of consultants and developer worked on that server, so it was bigger trouble to reboot it contemporary.

Blank, last page in SSRS-Report

nospam@example.com (Addicted2AX) — Mon, 19 Sep 2011 19:53:22 +0200

Ok, it took some time but here is a new entry. A short one.

You may face this problem sooner or later, when creating a SSRS-report with SQL Server 2008. It can happen with both plain Reporting Services and SSRS with Dynamics AX 2012.

After creating a report all looks fine, till you reach the end of the report. Although the last page with report-data has plenty of space left, there is a last completely empty - meaning white page – at the end of the report.

With Reporting Services for SQL Server 2005 you did not face this kind of problem, because white spaces are removed automatically. This is not a bug just a changed behavior.

But how to solve this problem with SQL Server 2008?
Quite simple: Just select the properties of the report. Look for the ConsumeContainerWhitespace-property. If the value is FALSE change it to TRUE and your problem with a last white page in SSRS-reports should be history.

Tipp: If you have the problem that there is a page with report-data, followed by a blank one, followed by a page with report data, a blank one and so on, the problem is different but as easy to solve. Just make sure that Body Width of the report + Left margin + Right margin are together smaller than the Page Width.

Checking the size of a database

nospam@example.com (Addicted2AX) — Tue, 02 Aug 2011 22:21:50 +0200

In this post I will show you a quick and easy way to find out how much space a specific database occupies on the hard drive.
Sure, you can check the properties of the database. But this is neither fast nor convenient.

In this case the build-in system stored-procedure sp_spaceused is useful.
Just select the database of interest and type in EXEC sp_spaceused and you will get a result like this:

The meaning of the columns as following:

database_name: The name of the database
database_size: The size of the database in Megabytes (including data & logs)
unallocated space: Space in database which is not allocated to database-objects

reserved: Total amount of space allocated by objects in the database
data: Total amount of space used by data
index_size: Total amount of space used by database indexes
unused: Reserved for database-objects but not used

Ok, not bad. But what would you do if you need this kind of information for every database on the SQL Server?
Of course you can execute sp_spaceused for every database. But this is also not very convenient.

For this kind of job there is another system stored-procedure. It is undocumented and therefore not officially supported by Microsoft. So please handle it with care.

The name of it is: sp_MSforeachDB.
Usage: EXECUTE master.sys.sp_MSforeachDB 'USE [?]; EXEC sp_spaceused'

The result would be like this:

You can perform a lot of other interesting and useful actions on your SQL Server with sp_MSforeachDB. In one of the next posts I will show you some other examples of usage.

Addicted2AX / Addicted2SQL - SQL Server

Dynamics AX 2012 & SQL Server 2008R2: Cross Join vs. Inner Join – Houston we have *NO* Problem

SQL Server performance-tuning with Instant File Initialization

Problems with SSRS & pdf-export after subsequent installation of fonts

Blank, last page in SSRS-Report

Checking the size of a database

Dynamics AX 2012 & SQL Server 2008R2: Cross Join vs. Inner Join – Houston we have NO Problem