D
dbeavon
Guest
It is my goal to determine whether it is likely or unlikely that the 10 second difference is related to going back to disk. I'd rather not do so much guesswork and/or get the evidence in a second-hand way. I am already convinced that the problem is disk, but I just need a conclusive and consistent repro. It shouldn't be so hard to clean the buffer memory and try again without restarting the whole database.*** A few years back someone mentioned that you could trick OE into going back to disk by "by dismounting and remounting the drives that house the database. " Has anyone found another such trick that has a similar effect and works in Windows? I'm looking for any ideas at all. EG ... could I do some type of an online SQL92 change to the database schema for the relevant tables ... in a way that essentially becomes a no-op .... but makes Progress think it needs to reload from disk? I am really quite convinced that there is a secret mechanism for doing this - similar to the "r-code trick" on the ABL code side of things (see KB P130577 where we force OE to reload r-code from disk with CURRENT-LANGUAGE = CURRENT-LANGUAGE). I'm betting Progress is just keeping it hard-to-find because otherwise someone will go and use it in a production environment. *** In SQL Server this is accomplished via "DBCC DROPCLEANBUFFERS". I just need the OpenEdge database equivalent.
Continue reading...
Continue reading...