On Dec 4, 2018, at 22:42, Simon Slavin wrote:
> On 5 Dec 2018, at 3:20am, Ryan Schmidt wrote: > >> $ sqlite3 /opt/local/var/macports/registry/registry.db >> SQLite version 3.25.2 2018-09-25 19:08:10 >> Enter ".help" for usage hints. >> sqlite> .load /tmp/macports.sqlext >> sqlite> pragma integrity_check; >> *** in database main *** >> On tree page 76852 cell 303: Rowid 18741471 out of order >> On tree page 76852 cell 301: Rowid 18741430 out of order >> On tree page 76852 cell 299: Rowid 18741387 out of order >> On tree page 76852 cell 296: Rowid 18741324 out of order > > It is possible that the rows reported as missing are actually deleted rows, > and that tree page 76852 just hasn't been moved from "part of TABLE ports" to > "freed pages". > > Try using ".dump" to dump that database to a text file. Can you read it and > tell whether anything is missing ? You can either read the SQL commands by > eye, or use command-line-tool to ".read" the .sql file to create another > database, and use database tools to interrogate that one. > > Does your database have any relations, either explicitly declared using > FOREIGN KEY or implicit in how your software handles the data ? Presumably > every row in TABLE file should be part of a row in TABLE port, or something > like that. Can you use your understanding of the relation to prove that > certain rows are missing from certain tables ? Does it give you any idea how > much data is missing ? Thanks very much for taking the time to respond. I'll look into what you suggested. >> the VMware virtual machine the builder runs on froze and had to be manually >> powered off. Upon restarting the VM, registry operations began failing with >> the above error. > > I'm 95% certain that your VMware software was caching changes made to the > database file rather than flushing them to disk when the software told it to. > Under default configuration they all do this, and this does not mean that > VMWare is worse than any competing product. > > In other words, the cause of corruption was that you were using a virtual > machine and not real hardware, and that the virtual machine violates ACID for > speed. It's possible that WMware has settings which correct this problem. > If it does, using them will, of course, slow it down. That occurred to me as well. But from what I can tell initially, writes should not be cached: https://kb.vmware.com/s/article/1008542 "VMware ESX acknowledges a write or read to a guest operating system only after that write or read is acknowledged by the hardware controller to ESX. Applications running inside virtual machines on ESX are afforded the same crash consistency guarantees as applications running on physical machines or physical disk controllers." _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
