Choosing a SQL edition

Argos 7 ships with Microsoft SQL 2012 Express, a free version of Microsoft's SQL platform . Many customers wonder if they should be using SQL 2012 Standard instead of Express, and the answer is that it depends on a number of factors in your environment.

While Sepialine does not recommend using SQL Express in an Argos environment with more than 100 users, sometimes it is a necessity dictated by cost. The following is an explanation of the limitations of SQL Express, as well as some ways to limit the database requirements of Argos.

SQL 2012 Express

SQL Express includes all of the features of SQL that are necessary for a complete Argos installation. The main limitations are:

  • 1 CPU slot/ 4 cores (whichever is less), for example on an 8-core CPU, only 4 cores would be used, but if server has multiple 2-core CPUs, only 2 total cores would be used.
  • 1 GB RAM. This is where we see the bottleneck in Argos. The biggest performance hit comes when using Argos Manager. The Argos Desktop Client is usually immune from SQL performance problems (except in extreme cases), but running reports in Argos Manager will be significantly slower than on a server with more RAM.
  • Max database size is 10GB. This is overkill for Argos, the database will likely not get over 1GB in the first year or more.
  • 50 SQL Instances per server. Don't know what this means? Don't worry. Argos uses only one SQL instance, and one database.

The most noticeable limitation of SQL Express is RAM usage. SQL Server does almost all processing within RAM to increase performance. Once the 1GB limit is reached, additional processing occurs on the hard drive, which will slow down performance and put unnecessary usage on your drive hardware. Often the quickest way to increase performance on a server running SQL is to add additional RAM, but with SQL Express, this does not necessarily help.

How to work around SQL Express limitations:

  • Archive data regularly. Consider keeping only 6 months of "live" data in Argos. Moving older records to the activity archive will limit how many records are included in the filtered results in reports, and will reduce RAM requirements.
  • Keep the project, device and user lists in Argos tidy. After archiving, remove old entries like users who have left the company and print queues that are no longer used.
  • Reduce the SQL connection times in the Argos Communication Service. By default, the Communication Service retrieves new device lists, user lists, project lists and other information every few seconds, and posts billed records back to the database just as frequently. By decreasing the frequency of communication, we can limit the load on the SQL database without any significant user experience change. Contact Sepialine Support before making any changes to these settings.
  • Have users print through a print server instead of making direct connections to printers.

When to NOT skimp on SQL Server:

  • Using Argos Global Print for pull-printing on multiple devices
  • Environments with more than 3 servers running Argos Communication Service to support multiple office locations
  • Servers that have multiple applications using SQL Server on the same server

Because Argos 7 does most of the activity processing at the Communication Service layer, the SQL Server workload is not as high as you might find with other applications. We have found that SQL Express is typically adequate in environments that meet these criteria:

  • Less than 100 interactively tracked users
  • 1-3 remote offices
  • Argos Manager used in same office as SQL Server (remote connections to SQL Server benefit from additional RAM)

If you are currently using SQL Express on your server for another application, we recommend using a separate instance for Argos. The hardware limitations of SQL Express are per-instance; if you have one instance for BackupExec, and one for Argos, each instance can use one GB of RAM and one CPU. If both applications share one instance, they also share the one GB of RAM and one CPU.

SQL 2014 Standard

  • Can use up to 128 GB of RAM
  • Can use 16 CPU cores
  • No database size limit

SQL 2012 Standard

  • Can use up to 64 GB of RAM
  • Can use 16 CPU cores
  • No database size limit

Other SQL Versions

The following additional versions are also supported:

  • 2012 Enterprise (overkill for most Argos environments)
  • SQL 2012 Business Intelligence

The following versions are not recommended, and/or not supported:

  • SQL 2005/2008 (Standard or Enterprise)
  • SQL 2005 Standard
  • SQL 2005 Express
  • SQL Workgroup Edition
  • SQL Web Edition
  • SQL Compact Edition
  • SQL Developer Edition
  • Any SQL 2000 or earlier version

Upgrading from SQL Express to SQL Standard

If you are unsure whether SQL Express will meet your needs, you can start with Express, and if there are noted performance issues,  upgrade to SQL Standard at a later date. Microsoft supports direct upgrade of SQL Express to Standard. Alternately, the Argos database can be migrated to another server that already hosts SQL 2012 Standard.

Still have questions? Sepialine Support can help you determine the best SQL version for your environment.

Have more questions? Submit a request


Please sign in to leave a comment.