Finally, as in a FAQ from 6 years ago.
It's still a very useful step because you have at least 100 errors in your query database, a warning for excessive load and ongoing locked database errors. Clearly something is going wrong with your database, and this is not being widely reported and appears to be unique to your deployment, since you make a point of saying that it's happened again.
That makes me want to pay close attention to what else you have running alongside the Pi-hole processes, and how they are behaving, especially in regard to resource usage and i/o spikes.
Resetting the database will allow the symptom to be reset to look for causal factors if it happens again, eg other processes' resource and i/o usage, file size growth rates, voltage problems, power outages, storage failure, inadequate storage performance, certain applications or certain times triggering the problem, etc etc. These will help home in on the cause.
You might find the atop package useful. It works like top or htop but also logs processes, cpu, memory and storage and lets you explore usage historically. You can go back hours, days or weeks to explore usage in 10 minute chunks. There are various guides available, eg this and this. If / next time you get database corruption you can look back and analyse what was going on before it happened.
$ apt show atop