Occ maintenance:repair --include-expensive stucs at - Remove activity entries of private events

Gotzon · May 14, 2026, 10:13am

Support intro

Sorry to hear you’re facing problems.

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

Official documentation (searchable and regularly updated)
How to topics and FAQs
Forum search

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can.

The Basics

Nextcloud Server version (e.g., 29.x.x):
- 32.0.9
Operating system and version (e.g., Ubuntu 24.04):
- Ubuntu server 24.04
Web server and version (e.g, Apache 2.4.25):
- Server version: Apache/2.4.67 (Ubuntu)
Reverse proxy and version _(e.g. nginx 1.27.2)
- replace me
PHP version (e.g, 8.3):
- 8.2
Is this the first time you’ve seen this error? (Yes / No):
- yes
When did this problem seem to first start?
- after upgrading from 31 to 32
Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
- Bare Metal
Are you using CloudfIare, mod_security, or similar? (Yes / No)
- no

Summary of the issue you are facing:

Good morning, I have a question because I’m not entirely sure what to do. Today I updated my Nextcloud to version 32. My admin panel asked me to update the MIME types in my database, and I ran the command: sudo -u www-data php occ maintenance:repair --include-expensive. Everything seemed to be going well until it reached the part about removing activity entries of private events. After two hours, I had to stop and take my Nextcloud installation out of maintenance mode, as I needed it. I decided to check the size of my oc_activity file in the database and found the following:

±--------±----------+
| Rows | Size (MB) |

±--------±----------+
| 3754386 | 3159.11 |

±--------±----------+

The quickest possible solutions I’ve found are to manually edit my database and perform these two actions:

Option A (Recommended): Only delete calendar and event logs to preserve other activity history.

sql
```
DELETE FROM oc_activity WHERE object_type = 'calendar' OR object_type = 'event';
```
Usa el código con precaución.
Option B (Fastest): Completely wipe the activity history if the table size is massive (hundreds of MBs) and the command above hangs.

sql
```
TRUNCATE TABLE oc_activity;
```

My main question is: Would this delete all my users’ calendars? Would all the scheduled appointments be lost? Perhaps I should run the repair command on the weekend and let it run all weekend? (Although in these two hours of work, I haven’t seen the size of the database table decrease.)

Thank you very much for your attention; any advice is welcome.

Steps to replicate it (hint: details matter!):

execute sudo -u www-data occ maintenance:repair --include-expensive
wait for hours stuck at Remove activity entries of private events
It seems nothing changes in oc_activity

Log entries

Nextcloud

Please provide the log entries from your Nextcloud log that are generated during the time of problem (via the Copy raw option from Administration settings->Logging screen or from your nextcloud.log located in your data directory). Feel free to use a pastebin/gist service if necessary.

I cant find any log of this

Web Browser

If the problem is related to the Web interface, open your browser inspector Console and Network tabs while refreshing (reloading) and reproducing the problem. Provide any relevant output/errors here that appear.

not related to web browser

Web server / Reverse Proxy

The output of your Apache/nginx/system log in /var/log/____:

I think we dont need logs

Configuration

Nextcloud

The output of occ config:list system or similar is best, but, if not possible, the contents of your config.php file from /path/to/nextcloud is fine (make sure to remove any identifiable information!):

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "my.nextcloud.com"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "32.0.9.2",
        "overwrite.cli.url": "https:\/\/my.nextcloud.com\/",
        "htaccess.RewriteBase": "\/",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "mail_smtpauthtype": "PLAIN",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "has_rebuilt_cache": true,
        "updater.release.channel": "stable",
        "app_install_overwrite": [
            "circles",
            "news",
            "twofactor_email"
        ],
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "tls",
        "mail_sendmailmode": "smtp",
        "logfile": "\/var\/log\/nextcloud\/nextcloud.log",
        "maintenance": false,
        "theme": "",
        "loglevel": 0,
        "default_phone_region": "ES",
        "allow_local_remote_servers": true,
        "trashbin_retention_obligation": "30",
        "default_locale": "eu_ES",
        "maintenance_window_start": 1,
        "skeletondirectory": "",
        "activity_expire_days": 365
    }
}

Apps

The output of occ app:list (if possible).

Enabled:

activity: 5.0.0
admin_audit: 1.22.0
app_api: 32.0.0
bruteforcesettings: 5.0.0
calendar: 6.4.0
circles: 32.0.0
cloud_federation_api: 1.16.0
comments: 1.22.0
contacts: 8.3.10
contactsinteraction: 1.13.1
dashboard: 7.12.0
dav: 1.34.2
deck: 1.16.4
federatedfilesharing: 1.22.0
files: 2.4.0
files_downloadlimit: 5.0.0
files_pdfviewer: 5.0.0
files_reminders: 1.5.0
files_sharing: 1.24.1
files_trashbin: 1.22.0
files_versions: 1.25.0
firstrunwizard: 5.0.0
forms: 5.2.7
logreader: 5.0.0
lookup_server_connector: 1.20.0
news: 28.3.0
nextcloud_announcements: 4.0.0
notes: 5.0.0
notifications: 5.0.0
oauth2: 1.20.0
ownershiptransfer: 1.4.0
password_policy: 4.0.0
photos: 5.0.0
privacy: 4.0.0
profile: 1.1.0
provisioning_api: 1.22.0
quota_warning: 1.23.0
recommendations: 5.0.0
related_resources: 3.0.0
richdocuments: 9.0.6
richdocumentscode: 25.4.904
serverinfo: 4.0.0
settings: 1.15.1
sharebymail: 1.22.0
spreed: 22.0.12
support: 4.0.0
survey_client: 4.0.0
suspicious_login: 10.0.0
systemtags: 1.22.0
tasks: 0.17.1
text: 6.0.2
theming: 2.7.0
twofactor_backupcodes: 1.21.0
twofactor_totp: 14.0.0
updatenotification: 1.22.0
user_status: 1.12.0
viewer: 5.0.0
weather_status: 1.12.0
webhook_listeners: 1.3.0
workflowengine: 2.14.0
Disabled:
appointments: 2.6.2 (installed 2.6.2)
bbb: 2.9.1 (installed 2.9.1)
encryption: 2.20.0
federation: 1.22.0 (installed 1.6.0)
files_external: 1.24.1
polls: 8.6.3 (installed 8.6.3)
qownnotesapi: 26.2.2 (installed 26.2.2)
twofactor_email: 2.8.8 (installed 2.8.8)
twofactor_nextcloud_notification: 6.0.0
user_ldap: 1.23.0

Tips for increasing the likelihood of a response

Use the preformatted text formatting option in the editor for all log entries and configuration output.
If screenshots are useful, feel free to include them.
- If possible, also include key error output in text form so it can be searched for.
Try to edit log output only minimally (if at all) so that it can be ran through analyzers / formatters by those trying to help you.

ernolf · May 14, 2026, 9:10pm

Hi @Gotzon,

to answer your main question directly:
no, deleting from oc_activity will not touch your calendars or appointments.
The oc_activity table is purely an activity log — it records events like “user X shared file Y” or “user X created calendar event Z”. The actual calendar data lives in completely separate tables (oc_calendarobjects, oc_calendars, etc.). Option A is safe.

What the repair command is doing is removing log entries that reference private calendar events — not the events themselves. Your calendars are not at risk.

With 3.7 million rows and 3.1 GB, a DELETE operation on oc_activity can take an extremely long time if there is no index on the columns being matched (object_type). Additionally, InnoDB does not immediately release disk space after a DELETE — the freed pages are held internally for reuse, so the physical file size will not visibly shrink while the operation is running. This is normal behaviour, not a sign that nothing is happening.

What to do instead of waiting all weekend:

Rather than running Option A as a single large DELETE (which will hold locks and may time out), delete in batches. Run this repeatedly in your MySQL client until it reports 0 rows affected:

DELETE FROM oc_activity 
WHERE object_type IN ('calendar', 'event') 
LIMIT 10000;

This is gentler on the database, keeps locks short, and lets you monitor progress.

After the cleanup, you can reclaim the disk space with:

OPTIMIZE TABLE oc_activity;

Before running OPTIMIZE TABLE, put Nextcloud into maintenance mode first — it locks the table for the duration and you do not want concurrent writes from Nextcloud interfering:

sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --on
# run OPTIMIZE TABLE oc_activity; in your MySQL client
sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --off

One more thing: your config has loglevel: 0 (DEBUG). That is extremely verbose for a production instance and generates a large amount of log output continuously. For normal operation, loglevel: 2 (Warning) is more appropriate — and if your installation is stable, loglevel: 3 (Error) is entirely sufficient.

h.t.h.

ernolf

Gotzon · May 15, 2026, 7:46am

Good morning,
First of all, thank you for your response. Everything is very clear now, and you’ve put my mind at ease. If you don’t mind, I’d like to ask you a couple of questions that have come up:
1- Given the size of the table, even though I’ve reduced it to 1 year of activity, it still seems to be taking up a huge amount of space. I’m considering reducing the activity to 3 months. To clean the table, would you recommend doing it from MySQL? I think it would be faster. The command I was thinking of using would be:
DELETE FROM oc_activity WHERE timestamp < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 90 DAY));
OPTIMIZE TABLE oc_activity;

2- Related to this, in my config.php file, I have “activity_expire_days”: 365. After cleaning it, I assume I should change the 365 to 90 in that line, right?

3- If it’s not too much trouble, I have a question about maintaining the database on my Nextcloud installation. It’s a fairly old installation; in its early years, the server was Owncloud, and then I migrated to Nextcloud, so you can imagine how old the database is. I’ve been doing some research to try and “reduce” the database size, such as deleting calendar entries older than 365 days and the same for document versions, but the only thing I’ve found is that it uses MySQL. Is there a Nextcloud app or tool I might have overlooked that could help with database maintenance?

4- Regarding your advice to change to loglevel 2 or 3, I hadn’t realized it was set to 0, so I’ve changed it right away. Thank you so much for being so observant.

And with all this rambling, I’ll say goodbye, but not before thanking you again; it’s been a very helpful answer for me.

ernolf · May 15, 2026, 9:26am

Glad it helped!

Timestamp-based cleanup

Your approach is correct — timestamp in oc_activity stores a Unix timestamp as an integer, so the comparison works exactly as you expect. That said, apply the same batching principle to avoid long-running locks:

DELETE FROM oc_activity
WHERE timestamp < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 90 DAY))
LIMIT 10000;

Repeat until 0 rows affected, then run OPTIMIZE TABLE in maintenance mode as before.

Reducing activity_expire_days to 90

Yes, this is exactly what the setting is for. Add it to your config.php:

'activity_expire_days' => 90,

The Activity app’s background job will then automatically delete entries older than 90 days on each run, so the table stays manageable going forward. 90 days is a reasonable value for a production instance — you still get meaningful history without accumulating years of log data. See the Activity configuration documentation for all available options.

Old file versions

For file version history (Files Versions app), you can clean up with:

sudo -u www-data php occ versions:cleanup

The retention behaviour can also be configured in config.php via 'versions_retention_obligation' — see the documentation for the available options.

Old calendar entries

Calendar objects (past appointments, etc.) live in oc_calendarobjects and are regular user data — Nextcloud does not automatically expire them, and there is no built-in occ command to bulk-delete old events. If you want to prune old appointments, that would need to be done at the CalDAV client level or carefully via SQL, and I would not recommend doing that without a solid backup in place first.

For backing up calendar and address book data as standard ICS/VCF files (which can be selectively re-imported afterwards), I can highly recommend the calcardbackup script by @Bernie_O — a well-maintained bash script specifically written for Nextcloud.

General database tuning

Since you mention the installation is quite old, it may be worth running MySQLTuner against your database. I use it regularly to find weak spots in MySQL configuration — buffer sizes, query cache, and other parameters. The project is still actively maintained and continues to receive contributions, which means its recommendations stay current.

h.t.h.

ernolf

Gotzon · May 15, 2026, 11:35am

You’re a lifesaver!! Thank you so much for all the information, it’s been incredibly helpful!!

Thanks again!