# Operate a Coordinator DB service

A service needs explicit configuration, working credentials and a known database path. Start from the installation procedure, then verify the interface your application will use. A successful unauthenticated health check does not establish authenticated SQL access.

Use [configuration files](https://coordinatordb.com/docs/concepts/features/configuration/server-config/configuration-files) to locate listener, user and log options. XML edits require a restart. Database settings have separate persistence and transaction rules, and `system.settings` reports effective values rather than every server-only XML option.

For observation, use [active requests](https://coordinatordb.com/docs/reference/system-tables/processes) for current work and [query history](https://coordinatordb.com/docs/reference/system-tables/query-log) for recorded terminal events. Keep query IDs with error reports. Diagnostic file logging and structured request logging are separate controls.

For recovery, use [database copies](https://coordinatordb.com/docs/concepts/features/backup-restore/local-disk) and test reopening an independent copy. For retention, review a cutoff and apply an explicit DELETE; do not wait for an automatic TTL queue.

Respect the [file-sharing model](https://coordinatordb.com/docs/get-started/about/deployment-modes): multiple client applications connect to one server process, while separate instances use independent files. Document the chosen credentials, listener addresses and recovery steps without publishing secrets or private row data.