C
ChUIMonster
Guest
Yes, you can put the whole DB in memory. You would need to run the db client/server rather than shared memory but the db could run with 64 bits and the clients remain 32 bit. That would save you the time required to get your OCX's and such changed. And since this sounds like Windows there is a pretty good chance that you are already setup that way. Run a "dbanalys" to load the whole db into memory without actually writing all of those queries 
You can also almost certainly get just as good performance with some pretty basic tuning. On 9/9/14, 11:31 AM, peggycole wrote: Buffer the whole database Thread created by peggycole Hi, One of our customers asked us why we don't put the whole database in memory at start up of the database. His idea is that when the whole database is buffered, his application would be x times faster. We're talking about a database with the size of +/- 35 GB. The applications works with OE 10.2B 32-bit. If we decide to do the buffering we have to move to OE 11 64-bit because the _mprosrve-processes will become bigger then 4GB. The migration to 64-bit would take us some time because of the use of multiple ocx's in the applications. So before we even try to set this up: do you think this is a good idea? IMO it isn't but I want to give it a try if the customer asks for it. Even if it is to proove it's not working. But because of the extra work it will cost considering the ocx's, i'm not very keen to start with this exercise if we know in advance.it will give us no gain. We do have some performance issues in the application and I think it 's better to fix them instead of doing some hocus pocus to cover them. But I want some decent arguments for that ... Another point against making the buffer as big as the database: The buffer has to fill itself initially. We can write queries on all the different tables and indexes after a restart but that just doesn't feel right and I just do not want to do this. Any comments? Kind regards, Peggy Stop receiving emails on this subject. Flag this post as spam/abuse. -- Tom Bascom 603 396 4886 tom@greenfieldtech.com
Continue reading...
You can also almost certainly get just as good performance with some pretty basic tuning. On 9/9/14, 11:31 AM, peggycole wrote: Buffer the whole database Thread created by peggycole Hi, One of our customers asked us why we don't put the whole database in memory at start up of the database. His idea is that when the whole database is buffered, his application would be x times faster. We're talking about a database with the size of +/- 35 GB. The applications works with OE 10.2B 32-bit. If we decide to do the buffering we have to move to OE 11 64-bit because the _mprosrve-processes will become bigger then 4GB. The migration to 64-bit would take us some time because of the use of multiple ocx's in the applications. So before we even try to set this up: do you think this is a good idea? IMO it isn't but I want to give it a try if the customer asks for it. Even if it is to proove it's not working. But because of the extra work it will cost considering the ocx's, i'm not very keen to start with this exercise if we know in advance.it will give us no gain. We do have some performance issues in the application and I think it 's better to fix them instead of doing some hocus pocus to cover them. But I want some decent arguments for that ... Another point against making the buffer as big as the database: The buffer has to fill itself initially. We can write queries on all the different tables and indexes after a restart but that just doesn't feel right and I just do not want to do this. Any comments? Kind regards, Peggy Stop receiving emails on this subject. Flag this post as spam/abuse. -- Tom Bascom 603 396 4886 tom@greenfieldtech.comContinue reading...