search

ChuckPa / PlexDBRepair

Database repair utility for Plex Media Server databases
Other
885 stars 43 forks source link

Best practice for IGNORE parameter? #135

Closed liquid-ion closed 9 months ago

liquid-ion commented 9 months ago

Had a bad database before the IGNORE function was added.

AUTO

reported a unique constraint issue, and couldn't complete the REPAIR. I instead used REPLACE and recovered a backup from a few days prior.

1) Had I used this newer version, could I have instead turned on IGNORE when I saw the unique constraint issue, then rerun AUTO?

2) I noticed IGNORE mentions that a bad database will never be created. Should this be used anytime a unique constraint error is encountered?

3) Is there any downside to using IGNORE when a unique constraint issue is encountered or is there a better way to fix?

Thanks

ChuckPa commented 9 months ago

  1. Yes you could have ignored the constraint error however "Auto" and "Repair" only differ by the final REINDEX which occurs with AUTO.

  2. Recommendation is to ONLY ignore errors when you confirm they are constraint. Ignoring other errors means you can create an incomplete or contradictory database (which only PMS will be able to detect)

It's important to remember, this tool is primarily concerned with the PHYSICAL "DB" file. It has NO MEANS to validate the contents of the DB for error / completeness.

liquid-ion commented 9 months ago

Sounds good. To summarize the best practice for IGNORE and unique constraints. The setting should be left as HONOR by default, and for most cases.

If a unique-constraint error is reported from the REPAIR, then to activate the IGNORE and then rerun the REPAIR.

If there are any other errors besides the unique-constraint issue, then setting IGNORE shouldn't be done since it could create an incorrect DB. Using REPLACE is better for these cases.

ChuckPa commented 9 months ago

The common use of IGNORE is for CONSTRAINT errors.

By default, the tool HONORs errors

The use case is importing watch history from another DB into the active DB. There will always be overlapping ID numbers because they are auto-increment starting at 1.

It's really meant as a last-ditch effort to save a DB when the next step is a full rebuild from scratch It shouldn't be used on an otherwise healthy database.

You asking me about when and how to use it during normal operation is concerning. Don't overthink this. This is a setting which can be used when all else fails. (when you have no backups anywhere to use and what you do have is damaged)