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 sent to the Log API or picked up by Log Agents. 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.

Understanding Log Databases

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

There is always exactly one online (active) Log Database, which receives new data, and any number of archive Log Databases, which hold older data and are still searched from Log Views. Administrators see the list in the Web Client under Administration › Settings › Log Databases.

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.

Large data volumes and high transaction counts require scaling hardware and software for the Nodinite environment. See 'Prerequisites' for more information.

How a New Log Database Is Created

The installer doesn't create a Log Database: the Logging Service creates the first one when it starts for the first time, with the same steps as below. With the right access rights, automatic log archiving is built into Nodinite. Log Databases split on Size and/or Time, governed by System Parameters stored in the Configuration Database. When the online Log Database is larger than SizeToSplitDatabaseOn or older than DaysToSplitDatabaseOn, the Logging Service creates the next one:

• Deployment – the Logging Service deploys the Log Database schema with SqlPackage.exe from SqlPackageExecutable, using the connection options in SqlPackageParams, on the SQL Server described by SqlServer
• Name and files – the name comes from LogDatabaseName; data, index, and transaction log files go to the folders in LogLocations, or to the SQL Server defaults when it is empty
• Recovery and access – the recovery model comes from LogDatabaseRecovery, and every account in LogServiceUsers gets the roles in LogAccessRoles
• Always On – on an Always On Availability Group, the backup the secondary replicas restore goes through the share in AvailabilityGroupBackupPath
• Switch – the new database becomes the online Log Database and the previous one becomes an archive Log Database; DatabaseMaintenance then keeps the indexes healthy and shrinks archive Log Databases

The SizeToSplitDatabaseOn page has the step-by-step sequence.

If Nodinite is not given elevated rights, your organization may need to create new Log Databases manually to avoid performance issues. See Create new Log Databases Manually and always follow the naming scheme in the LogDatabaseName System Parameter.

Log Database Naming

New Log Databases are named by the LogDatabaseName pattern, which the installer sets to Nodinite_<EnvironmentName>_Log_{year}{month}{day}, for example Nodinite_Prod_Log_20251028. The environment part comes from EnvironmentName; it is not validated, so SQL Server naming rules are the limit. Use letters, digits, and hyphens, and don't change it after installation.

Note

Existing databases are not renamed when you upgrade. Log Databases created by Nodinite v6 keep their NodiniteLog_<EnvironmentName>_{date} names, and the Configuration Database keeps NodiniteConfig_<EnvironmentName> (new installations use Nodinite_<EnvironmentName>_Config).

System Parameters for Log Databases

These System Parameters control how Log Databases are created and maintained. The Logging Service reads them (except EnvironmentName, which reaches the names through the LogDatabaseName pattern), and a change takes effect within about 15 seconds without a restart; most apply to the next Log Database it creates. Change them as described in Manage System Parameters.

Recovery Model, Always On, and SQL Server Options

• Recovery model – the default is SIMPLE, recommended especially when Nodinite shares the SQL Server instance with BizTalk Server. On an Always On Availability Group it must be FULL. See LogDatabaseRecovery.
• Always On Availability Groups – see Always On Availability Groups and AvailabilityGroupBackupPath.
• Linked Servers – always required, even on a single instance; see Linked Servers.
• SQL Server options – see SQL Server Options.

Install, Update, and Remove Log Databases

• Install – Log Databases ship with the Core Services. You set the SQL Server type and connection string in the Nodinite Portal, Step 3: Infrastructure. See Install Log Databases.
• Update – after a Core Services update, the Log Database schema is updated with the Update Log Database guide in the Web Client. See Update Log Databases.
• Add or edit – register, edit, or set a Log Database read-only in Add or manage a Log Database.
• Remove – see Uninstall Log Databases and, for old archives, Automating removal of old Log Databases.

Frequently Asked Questions

Find answers on size, recovery models, and high availability in the Log Databases troubleshooting guide.

Next Steps

• Add or manage a Log Database
• Update Log Database
• Manage System Parameters

Related Topics

• Log Databases administration
• Configuration Database
• Prerequisites
• Logging Service
• Log API
• Monitoring Service
• System Parameters
• Always On Availability Groups
• Moving Nodinite Databases
• Troubleshooting