Skip to Content

The system environment can have huge impact on SAP Business One performance in general therefore I would like to have closer look at some key aspects. Under the term system environment we understand it as hardware and software components such as operating system, 3rd party software, database and SAP Business One components.

First of all it is good industry practice to meet the minimum hardware and software requirements. Although these requirements are essential to use the software and gives us a rough estimation for a new Business One implementation a real implementation requires higher hardware resources for optimal usage. This is due to the fact that a specific implementation with user customizations is more demanding and the amount of data  generally negatively impacts the performance and requires more OS resources. The following table shows some of the minimum hardware requirements.


Server platform


SAP Business One 2005

SAP Business One 8.8/8.81


1x Intel Pentium 4 (or equivalent)

1x Intel Pentium 4 (or equivalent)


1 GB

1 GB

Free Hard Disk

System partition 0.5 GB

Data partition 2 GB

System partition 0.5 GB

Data partition 2 GB





640 x 480 with 256 colors or higher

640 x 480 with 256 colors or higher

You can check the SAP PartnerEdge portal for the latest information about supported platforms. -> Product availability > Supported Platforms


Sharing the SAP Business One server with non-SAP Business One services such as file server, email server etc. use some of the system resources like IO, CPU, RAM etc. which could be used by the database server MSSQL during the system resource shortage. Any system resource shortage can cause delay in the database response time which users would interpret as a slow SAP Business One client response. If further degradation occurs the SAP Business One client may into non-responding mode when waiting long time for a database response. With additional services on the overloaded server under specific conditions can often cause random performance slowdowns which cannot be replicated in a testing environment. Therefore moving non SAP Business One services from the SAP Business One server would be the first thing to do when experiencing performance problems.

I would like to mention about memory implications. To understand about the memory implications I want to first explain MSSQL caching and memory management. First question we should ask is why is caching needed? In MSSQL context caching means storing some pages (data form file system) in RAM. Thanks to caching SQL Server does not have to read the data from file system but rather uses data from cache. Reading data from the file system is approximately 1000 times slower than reading them from RAM therefore caching can significantly improve the MSSQL performance especially in data retrieval (SELECT statements). Data retrieval operations occur very often in a database system even in a transactional system like SAP Business One due to the data validation. SQL Server tries to reserve as much RAM as possible but must also consider the RAM needed by the operating system to function. Therefore when there is not enough available RAM SQL Server frees the oldest data from the cache and this RAM is released back to the operating system. To analyze the memory shortage you use the Windows performance monitor (perfmon) to check system resources like paging file and cache hit ratio. These important metrics such as paging file should as low as possible as a reliance on this would be a concern. The MSSQL cache hit ratio is optimal if hitting rates between 90 – 95%.  Furthermore SQL Server memory can be influenced by AWE settings on 32-bit system as a 32-bit application can use a maximum 2GB of addressable RAM space. Ticking the AWE option in SQL Server causes allocation of more memory through child SQL Server threads. In 64-bit environment the AWE option makes no sense as 64-bit systems can address 2^63 bytes of memory.

When talking about SQL minimum and maximum memory requirements these parameters are particularly relevant especially when there are additional processes other than SQL Server running. Here I am talking about the DI Server or a web or email server or B1i. So what does minimum and maximum server memory really mean? It specifies that SQL Server should start with at least a minimum amount of allocated memory and not to release memory below this threshold. Maximum server memory specifies the maximum amount of memory the SQL Server can allocate when it starts and while it runs. Let’s see an example. We have an server allocated 4GB of RAM with SAP Business One server running which means SQL Server is installed. In addition we also have services for the license server, the DI Server, a web server and B1i running. From experience we know that the license server, DI server, web server and B1i need at least 1GB of RAM and during the high load it could need 2GB for optimal work. So the minimum memory for SQL Server should be set to 1GB to guarantee that not all the available memory will be used by these additional services. The maximum memory for SQL Server should be set to 2GB to ensure enough memory for non SQL Server processes. The remaining 1GB of memory should remain available for the system processes which have always the highest priority. So approximately 1GB of RAM can be used between the SQL Server and License server, DI Server, web server and B1i depending on the needs and load.

It is important to mention about server and database collation settings as the collation is important for the sorting purposes and can be set for whole SQL Server instance or for particular objects such as database, table, column etc. While the database collation is set by the SAP Business One application when creating a new company the SQL Server collation can be set during the SQL Server installation. Why is the collation important? As mentioned above it is used for sorting purposes and depending on the collation textvalues might be sorted differently. Comparing values with different collations can return an SQL error plus there are known problems with incorrect server collation like that an upgrade can fail. Therefore it’s necessary to follow the SQL Server installation manual to set correct SQL Server collation. The server collation can be verified by the SQL query: SELECT SERVERPROPERTY (‘collation’)

The recovery model is a database option and can be set for each database. The recovery option can be set to simple, bulk-logged or full. The decision as to which model to choose is at discretion of each customer and it depends on the customer needs and priorities. What are the pros & cons of each model?

>  Simple recovery model does not contain log backups

  • Pros: Eliminating the need to manage the transaction log space.
  • Cons: Changes since the most recent backup are unprotected. In the event of a disaster, those changes must be redone. Can recover only to the end of backup.

>  Bulk logged recovery model requires log backups.

  • Pros: High performance bulk copy operations. Reduces the log space.
  • Cons: Changes after last log backup must be redone. Point in time recovery is not supported.

> Full recovery model also requires log backups.

  • Pros: Normally no data loss. Can recover to a specific point in time.
  • Cons: The biggest log file which needs to be managed.

And finally for the virtual memory recommendations I would like to mention that once it comes to writing RAM to virtual memory the performance is decreased dramatically. On the other hand once the operating system exhausts all RAM resource the critical operations might fail therefore to prevent this situation we recommend setting the virtual memory according Microsoft’s recommendations.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply