What is a Log Database?
Nodinite Log Databases deliver scalable, secure, and high-performance storage for all your integration data. This page explains how Log Databases work, how they grow with your business, and how they keep your data protected and accessible for compliance, analytics, and troubleshooting.
What you'll learn on this page:
✅ Effortlessly scale storage for unlimited integration data
✅ Maintain high performance as data volumes grow
✅ Secure sensitive data with built-in obfuscation
✅ Automate archiving and partitioning for compliance and cost control
✅ Simplify administration with seamless integration and self-healing features
Nodinite logs events and messages from your system integration brokers (Mule, BizTalk, ...) and custom solutions using Log Events. All this data is persisted for long-term storage in SQL Server-based databases known as Log Databases. As data volumes grow, traditional relational databases can suffer performance hits, and SQL Express limits storage to 10GB per database. Nodinite overcomes these limitations by automatically spawning new Log Databases as they grow too large or too old. You never need to worry about which database your data is in—Nodinite manages it all behind the scenes using the Configuration Database.
During the first start of the Logging Service while performing the installation of Nodinite, a SQL Database prefixed NodiniteLog_ is created for each environment (e.g., NodiniteLog_Prod_, NodiniteLog_Test_). The Log Database is part of the Core Services package, and the Nodinite Update Tool provides scripts for administrators to update one or more Log Databases. See Prerequisites for pre-installation information.
The Configuration Database interacts with and depends on the Log Databases using Linked Server connections and configured security settings. The Core Services Overview and 'Prerequisites' pages detail all required SQL, Windows, and firewall settings.
Having the Log Databases on the same SQL Instance as the Configuration Database reduces administration for firewalls, distributed transactions, and more.
Overview of Nodinite Configuration Database interacting with the Log Databases using a linked server
Sensitive data within the Log Databases is protected using an obfuscator, so a SQL DBA cannot read the content or context properties of messages like patient journals and salary payments.
Data is partitioned over time into multiple Log Databases. This feature improves performance and enables virtually unlimited storage, both horizontally and vertically. Your hardware is the limit, not Nodinite
System administrators can put historical Log Databases in read-only mode.
With the right access rights, automatic log archiving is built into Nodinite. Log Databases split on Size and/or Time, governed by runtime values in the System Parameters table in the Configuration Database.
- SizeToSplitDatabaseOn – Maximum size (in GB) before a new Log Database is created
- DaysToSplitDatabaseOn – Number of days since creation before a new Log Database is created
- LogDatabaseName – Default naming convention for new Log Databases
Large data volumes and high transaction counts require scaling hardware and software for the Nodinite environment. See 'Prerequisites' for more information.
If Nodinite is not given elevated rights, your organization may need to create new Log Databases manually to avoid performance issues. Always follow the naming scheme detailed in the LogDatabaseName System Parameter user guide.
Once created, Log Databases must have the appropriate SQL rights set. The following System Parameters are used by the Logging Service to automatically set access rights on new Log Databases:
- LogAccessRoles – Database role(s) to grant the service user(s) access to new Log Databases
- LogServiceUsers – Service user(s) to grant access to new Log Databases