table AdminServiceLogs, BPS_Config`database grew significantly

0

Hi,
Have you tried using the "Clear all diagnostic data" button?

Thanks! Yes, I tried, but nothing changed after clicking 'Clear all diagnostic data' button.

Hey,
Jacek's suggestion with the "Clear all diagnostic data" button is probably the easiest way to go, though running a TRUNCATE on AdminServiceLogs should be safe as well. I'd definitely test this out on your DEV/TEST environment first just to be sure.

Hi,

Please note that Diagnostic logging mode "Debug" (configured in https://docs.webcon.com/docs/2026R2/Studio/SystemSettings/GlobalParams/ ) *DOES NOT* log to configuration database. It logs to content database, table "AdminDebugLogs".
The amount of logs in BPS_Config.dbo.AdminServiceLogs is related to "Database log level" configured in Services configuration (https://docs.webcon.com/docs/2026R2/Studio/SystemSettings/ServiceConf/ ). Make sure it is not set to Debug or Info.
If the AdminServiceLogs is too big, the supported way of removing data is by scheduling "Database maintenance hours" - see https://docs.webcon.com/docs/2026R2/Studio/SystemSettings/ServiceConf/Schedules/#3-database-maintenance-hours .

However, in emergency situations such as this, I would suggest:
1. copying the content of AdminServiceLogs to another custom table, to not lose logs if they're needed in the future (SELECT INTO AdminServiceLogs_copy or something like that)
2. truncate the original table in BPS_Config database

Thanks, Konrad! Yes, debug logging was enabled in the service configuration settings (I made a mistake when write the question), but that setting was changed to "ImportantInfo" a long time ago. The maintenance plan has run multiple times since then, yet the size of the `AdminServiceLog` table remains unchanged ( it occupies 10 GB). Thanks for the advice! We executed: 1.truncate the table, 2.shrink the `BPS_Config.mdf` file, 3.rebuild indexes and 4.update statistics. Now all work without problem and there are free disk space.