I have not had to do this, but I remember seeing others mention this process.
it went something like this: - TURN OFF the indexes through out the database. - let compact do its job - TURN ON indexes through out the database - let database index -- not sure if this is needed/helps but you might want to look at turning off triggers too. Chip On Thu, 26 Jul 2018 09:47:00 -0500, John DeSoi via 4D_Tech wrote: > I had a very stable 16 user database with 4D 15 32-bit Mac. After > upgrading to 4D 16 64-bit Mac (on 16.3HF4), 4D server has been > crashing about twice a month. There is no consistency on the process > or records involved in the crash. The only consistency is the > backtrace of the internal 4D routines involved. Here are some samples. > > Thread 93 Crashed:: Import (id = 133091) > 0 libsystem_kernel.dylib 0x00007fff7f337b6e __pthread_kill + 10 > 1 libsystem_pthread.dylib 0x00007fff7f502080 pthread_kill + 333 > 2 libsystem_c.dylib 0x00007fff7f2931ae abort + 127 > 3 libsystem_malloc.dylib 0x00007fff7f39cad4 szone_error + 596 > 4 libsystem_malloc.dylib 0x00007fff7f39e0eb > small_free_list_remove_ptr_no_clear + 790 > 5 libsystem_malloc.dylib 0x00007fff7f392061 > small_malloc_from_free_list + 171 > 6 libsystem_malloc.dylib 0x00007fff7f390859 > szone_malloc_should_clear + 1600 > 7 libsystem_malloc.dylib 0x00007fff7f3901bd > malloc_zone_malloc + 103 > 8 libsystem_malloc.dylib 0x00007fff7f38f4c7 malloc + 24 > 9 com.4d.component.db4d 0x000000010f052e19 > VDBCacheMgr::NewPtr(unsigned long, unsigned char, int, int) + 25 > 10 com.4d.component.db4d 0x000000010f399c00 > TreeMem::PutInto(int, int, void*, OccupableStack*) + 256 > 11 com.4d.component.db4d 0x000000010f39e26c > TreeMemHeader::PutIntoTreeMem(int, int, void*, OccupableStack*) + 428 > 12 com.4d.component.db4d 0x000000010f125e2d > DataTableRegular::LoadRecord(int, unsigned long long&, > DB4D_Way_of_Locking, BaseTaskInfo*, unsigned char, unsigned char, > ReadAheadBuffer*, unsigned char*) + 1053 > > > Thread 77 Crashed:: CWR Export (id = 170783) > 0 com.4d.component.db4d 0x000000010f95ea6b > TreeMem::RetainFrom(int, int, OccupableStack*) + 139 > 1 com.4d.component.db4d 0x000000010f95ea9e > TreeMem::RetainFrom(int, int, OccupableStack*) + 190 > 2 com.4d.component.db4d 0x000000010f9636eb > TreeMemHeader::RetainFromTreeMem(int, OccupableStack*) + 75 > 3 com.4d.component.db4d 0x000000010f6eb7f7 > DataTableRegular::LoadNotFullRecord(int, unsigned long long&, > DB4D_Way_of_Locking, BaseTaskInfo*, unsigned char, ReadAheadBuffer*, > unsigned char*, unsigned char*) + 583 > 4 com.4d.component.db4d 0x000000010f6df737 > DataTable::Search(unsigned long long&, RechNode*, Bittab*, > xbox::VProgressIndicator*, BaseTaskInfo*, DB4D_Way_of_Locking, > Bittab*, int, Bittab&, LocalEntityModel*) + 3239 > 5 com.4d.component.db4d 0x000000010f8389d3 > RechNode::Perform(OptimizedQuery*, Bittab**, Bittab*, > xbox::VProgressIndicator*, xbox::VValueBag*, BaseTaskInfo*, > DB4D_Way_of_Locking, Bittab*, int, Bittab&, RechNode*&) + 163 > 6 com.4d.component.db4d 0x000000010f8469ca > RechNodeMultiOperator::Perform(OptimizedQuery*, Bittab**, Bittab*, > xbox::VProgressIndicator*, xbox::VValueBag*, BaseTaskInfo*, > DB4D_Way_of_Locking, Bittab*, int, Bittab&, RechNode*&) + 2058 > 7 com.4d.component.db4d 0x000000010f84da5f > OptimizedQuery::Perform(Bittab*, xbox::VProgressIndicator*, > BaseTaskInfo*, unsigned long long&, DB4D_Way_of_Locking, int, > Bittab*) + 1903 > 8 com.4d.component.db4d 0x000000010f6e0f12 > DataTable::ExecuteQuery(SearchTab*, QueryOptions*, QueryResult&, > BaseTaskInfo*, xbox::VProgressIndicator*) + 322 > 9 com.4d.component.db4d 0x000000010f690933 > VDBMgr::ExecExecuteQuery(IRequestReply*, CDB4DBaseContext*) + 259 > 10 com.4d.component.db4d 0x000000010f688253 > VDBMgr::ExecuteRequest(short, IRequestReply*, CDB4DBaseContext*) + > 1475 > 11 com.4d.component.db4d 0x000000010f697697 > VDBMgr::ExecuteRequest(short, xbox::IStreamRequestReply*, > CDB4DContext*) + 311 > 12 com.4d.component.db4d 0x000000010f9a4a64 > DB4DConnectionHandler::Handle(unsigned long long&) + 2036 > > > So it appears that 4D is crashing shortly after loading a record > (DataTableRegular::LoadRecord, DataTableRegular::LoadNotFullRecord). > The database is validated every night and reports no errors. Manual > check in MSC reports no errors. With no other solution in sight, it > is time to compact the database (70+ GB) and see if it makes a > difference. Here is what happens. > > 1. Open MSC, click on Compact, click on Advanced. Check "Force > updating of the records" and "Compact address table". Click the > compact button. > > The first bit of confusion is the path under "Original files backup > folder" is *not* a backup of the original database. It is the new > compacted database. > > 2. Wait for hours and the progress bar finally reaches the last table > and is pixels away from the end. Wait for many more hours, nothing > seems to be happening even though 4D is using 100% CPU. Finally > discover that 4D is indexing the database, but the indexing progress > window is hidden behind the MSC window. > > 3. Wait many more hours, progress bar for creation of a single index > on a table with 40 million records has barely moved. Cache used in > creation of the index shows 0%. The database memory setting is 4GB. > Activity Monitor shows 4D is using 300MB. I suspect when 4D restarts > to open the database for compacting that it ignores the database > memory settings. Indexing will never complete under these conditions. > > 4. Force 4D to quit. Trash the index file. Remove the "_" prefix from > the database in "Original files backup folder", then open the > database. It re-indexes normally with plenty of cache available. > > > My experience with compacting was the same using 4D 16.3HF4 and 17.0. > Anyone have a better experience with this on a large data file? > > John DeSoi, Ph.D. > > > > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** --------------- Gas is for washing parts Alcohol is for drinkin' Nitromethane is for racing ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
