If it’s not OK, you can do a Repair but only with the Pro version of SQLite Expert. Other tools are probably available but I have always used SQLite Personal for the maintenance of my DPL and Lightroom databases without any problem.
In the past when my pc slowed downn I did remove the antivirus, avg?, completely and installed it again. I think that was also a to large db issue.
What does the vacuum command do?
This command cleans the database by copying its contents to a temporary database file and reloading the original database file from the copy. This eliminates free pages, aligns table data to be contiguous, and otherwise cleans up the database file structure.
Some reorganisation. I never worked with SQlite or other look alikes. I once bought the first release Access and when I tried to print 2 lines I had to wait for such a long time that I stopped . For myself I use DBF.
@Pat91
How exactly did the problem show?
How many RAWs you had?
What kind of disk was used for DB?
How long it took for vacuum cleaning?
Do you think DPL backup/delete/restore would do the job?
I have some 80,000 old RAWs but I plan a cleanup, deleting probably 80%.
In future, some 90% of loaded photos will get deleted.
The DB is on a recent Kingston NVMe SSD.
No problem so far, but my DPL is only two months old.
Read the topic name. Your dpl database is loading slowly ?. Question mark. Then this might help.
If you don’t experience this problem, than it’s not meant for you.
It depends how DPL restores a backup database and how the backup was built. So, the process is apparently similar but you can’t be sure. A specialized software is probably preferable.
When I said “loading slowly”, I just meant slower than usual. Not only when DPL is starting but also when browsing folders. After I executed the “vacuum” process, I could browse much faster. But this may not apply to all situations. Anyway, this is a no-risk operation.
Thanks Patrick,
Just wondering if there was visible impact on exports.
I would guess it was few milliseconds per image, hence negligible.
My database may soon run into your problem,
but I don’t mind DPL starting 10 sec longer
and I don’t change folders that often.
The file is PhotoLab.db, which can be logically found in the folder pointed to by the “DxO Photolab Database | Location” field in the General tab of the Preferences dialog box.
A “vacuum” (which is not at all a standard DBA term) seems to be equivalent to a reorg, which can be achieved with an export and subsequent import.
But I seriously doubt it will yield much in the way of performance improvement. PL is a compute-bound program, spending most of its cycles calculating how an image would appear with the corrections applied. There is very little in the way of I/O as the program reads the corrections from the database, and I would be surprised if that’s more than 50K for any image.
With modern architectures of virtual memory, and machines built out to 32GB and more, the SQL*Lite engine (built into PL) will be cacheing as much of the DB as it can. Esoteric concepts such as page alignment and table contiguity really doesn’t apply for the small amount of I/O PL needs to do. It’s not recording thousands of transactions per second.
Regarding the symptoms reported by @Pat91, PL will slow down when you open a folder because it’s trying to calculate the proper rendering for all the images in that folder.
Off course I searched for that command in sql and its variants. The explanation of @Pat91 seems ok to me, an analog with the vacuum cleaner.
Last summer I updated my ram from 16 to 32. I don’t see any difference.
