This section describes the process of running PaperCut NG/MF on an external relational database, and describes why you would choose to do this. By default, PaperCut NG/MF uses an internal database product known as Apache Derby. This database engine was donated to Apache by IBM and was previously known as IBM Cloudscape.
PaperCut uses the database to store all of its configuration and print log data. The default Apache Derby database is used on 10,000’s of our customers PaperCut installations and has proven to be very stable, scalable, reliable and performant. It also has the advantage of being zero-administration, so there is no need to have DBAs to administer and maintain the database.
When should I run PaperCut on an External Database?
There are times when there is an advantage to running PaperCut on a dedicated external database system like Microsoft SQL Server, Oracle, Postgres or MySQL. These dedicated databases provide improved performance when running queries over large dataset (e.g. large reports), and also provide improved handling of concurrent operations to provide improved scalability and reduced database locking problems.
For sites with a large number of users, or a large printing volume it is generally recommended to run PaperCut on one of these external databases. Most organizations already have database installations so PaperCut can take advantage of the existing infrastructure (e.g. backups, maintenance, etc).
You might consider running PaperCut NG/MF on an external RDBMS if:
- Your organization has existing database infrastructure and wants to consolidate all applications on the same database platform.
- Your organization has an existing database maintenance and backup procedure and wants PaperCut NG/MF to take advantage of this.
- People want to use 3rd party reporting and analysis tools (like Crystal Reports or Microsoft Access) to view and analyze the PaperCut NG/MF database.
- Your organization is very large and requires the performance benefits of a dedicated RDBMS. This also allows the database to reside on a separate server to PaperCut NG/MF, which improves the system scalability.
See the PaperCut MF System Requirements and PaperCut NG System Requirements pages (under Database Servers) to see which external databases are supported out-of-the-box. These databases were chosen to cater for the majority of customers.
It’s also worth checking our PaperCut Server Sizing Guide for more information on the specifications recommended for the numbers of users and printers in your environment.
Note: if you’re already running on an external database, and you’re wanting to migrate your database to another server, check out Migrating your database server .
What indicates I need to run an external database?
The internal database will often meet a customer’s usage requirements, however there are indicators that a move should be made to an external database. These are outlined below:
Slow-running Reports
If you are running a report over a large data set (e.g. 1000s or millions of print log records) and find that the reports are running slowly, then it is recommended to upgrade to an external database. These external databases are optimized to handle large datasets efficiently.
Out of Memory errors running Reports
If you receive an “Out of Memory Error” running large reports, this can indicate that the internal database doesn’t have enough memory resources to complete the operation. External databases are better at handling large data and will not encounter these issues.
You should also ensure that your system has enough RAM. We recommend at least 2GB of RAM for busy servers. For more information on memory and PaperCut see the following KB article: Managing the amount of memory used by PaperCut NG/MF
Locking or Deadlock Errors
When databases insert/update/query data they obtain locks on the data/tables to ensure the data is consistent and valid. For most operations these locks are obtained for a very short period and do not affect the system. If there is a high level of activity, and large reports being run this can increase the amount of locking required. This can result in database locking errors occurring, like the following:
A lock could not be obtained due to a deadlock, cycle of locks and waiters is ….
A lock could not be obtained within the time requested.
In more recent versions of PaperCut when this error occurs a more friendly error message is displayed, System under heavy load.
If you are encountering these issues, we would recommend upgrading to an external database as outlined above. These dedicated external databases are designed to be highly scalable and provide optimized locking which reduces the likelihood of these problems.
Overloaded server
If your PaperCut print server is hosting PaperCut and all your print queues and is becoming overloaded. You can use an external database hosted on another server. This removes the disk and processing load associated with the database to a separate server, which makes more resources available for the print server.
What external database should I use?
PaperCut does not have a preference of external databases that should be utilized, and a large factor in deciding what external database you should use depends on your current knowledge of database administration. More information is available here .
What’s next?
See How to upsize to an external RDBMS for steps on moving from the built-in database, to an external database like Microsoft SQL Server, Oracle, Postgres or MySQL.
Comments