This is just a general question.

I believe it is good policy to run SQL "REPAIR TABLE XXX" from time to time on a database. In a "spring cleaning" type of way. I don't know how the internals of EDB work, so this might be totally unnecessary.

Are there any issues with using REPAIR where you have multiple instances of a database installed on multiple servers and they are using Replication to sync data?

I think all Update files generated by EDB ultimately trigger as SQL, so I guess it shouldn't make any difference, but I just wanted to be sure.

Adam


<<I believe it is good policy to run SQL "REPAIR TABLE XXX" from time to time on a database. In a "spring cleaning" type of way. I don't know how the internals of EDB work, so this might be totally unnecessary.>>

Sorry to disagree with you but I think its bad policy. Run a verify every so often and repair if it shows anything bad. Possibly do an optimise, but be prepared for a long wait if its a biiiig table. If a table is properly indexed and not a lot of row scans are done I don't think you'll gain much benefit even from optimising, apart from releasing disk space if you've been doing a lot of deleting.

<<Are there any issues with using REPAIR where you have multiple instances of a database installed on multiple servers and they are using Replication to sync data?

I think all Update files generated by EDB ultimately trigger as SQL, so I guess it shouldn't make any difference, but I just wanted to be sure.>>

I don't know but I'd guess that since "all" you're doing is passing sql commands around it won't pass broken tables around - any problems will be strictly local.

Roy Lambert

Roy Lambert wrote:

> but be prepared for a long wait if its a biiiig table

Indeed - one of the line-of-business time-cricital applications of mine used to verify at the startup of the service, and they complained that it took too long to get going. Not good in the middle of the working day. So I changed to only verify the small tables, and the big one was only checked if the _unclean_shutdown.txt was present. So if they killed it, I insisted on a check, but if it was closed nicely (the service deleted on shutdown that file it created on startup), then speed was golden.

--

Matthew Jones