Page 1 of 2

Speeding up a database

Posted: Thu Mar 21, 2019 3:55 pm
by RAMbo
I'm a proud PrimoCache owner that's considering getting even more proud by buying another Romex product.... :-)


I'm building a 130 million record database with 100 fields each.
Lots of filtering and searching.
A RAM disk should speed up things greatly I think.
What scares me is data securing.
A certain web scraping process will run for months.
Is it possible to let the RAMdisk copy a backup from the RAMdisk to my harddisk, say, every hour while the database is live?

Will PrimoCache interfere with the RAMdisk? I don't see how, but still want to be sure.
I could also get a dedicated SSD disk for just the database and allocated enough RAM to PrimoCache so the database will entirely fit in cache if needed.

Advise please.
Pros and cons of both approaches?

Re: Speeding up a database

Posted: Mon Mar 25, 2019 4:00 am
by Support
Usually Ramdisk or RAM caching is for TempDB only so that source DB data will not be affected.
RAMbo wrote: Thu Mar 21, 2019 3:55 pm Is it possible to let the RAMdisk copy a backup from the RAMdisk to my harddisk, say, every hour while the database is live?
Yes, you can set an file as backing image for the ramdisk, and set timing save.

Using PrimoCache is also applicable, but usually ramdisk is faster than cache, as there's no additional process to schedule caching blocks.

Re: Speeding up a database

Posted: Mon Mar 25, 2019 9:28 am
by RAMbo
http://www.romexsoftware.com/en-us/prim ... tures.html
Read and understood the difference between the version.
Is there any speed difference between the versions? (Assuming a 100% similar system and configuration)




Will the reloading of the RAMdisk image, at Windows reboot, be complete *before* any other program can try to acces the RAMdisk.

I ask because the program that will use the RAMdisk will start at Windows boot and starts accessing the RAMdisk immediately.

Re: Speeding up a database

Posted: Tue Mar 26, 2019 7:37 am
by Jaga
RAMbo wrote: Mon Mar 25, 2019 9:28 amWill the reloading of the RAMdisk image, at Windows reboot, be complete *before* any other program can try to acces the RAMdisk.

I ask because the program that will use the RAMdisk will start at Windows boot and starts accessing the RAMdisk immediately.
You can have it load the image at boot when kernel level drivers are being loaded, yes. It increases boot time, but user-level processes won't load before the RAMdisk is available.

Re: Speeding up a database

Posted: Tue Mar 26, 2019 8:48 am
by RAMbo
When you say "RAMdisk is available" do you also mean the image is loaded to the RAMdisk?

Re: Speeding up a database

Posted: Tue Mar 26, 2019 3:40 pm
by Jaga
Yes. The image fully loads even before the Windows login is presented.

Re: Speeding up a database

Posted: Tue Mar 26, 2019 3:42 pm
by RAMbo
Great!

Thanks for the input Jaga!

Re: Speeding up a database

Posted: Wed Mar 27, 2019 4:20 am
by Jaga
Hope it works the way you need it to. :)

Re: Speeding up a database

Posted: Wed Mar 27, 2019 6:08 am
by RAMbo
Well.... :-)

I installed the program. All works fine but I can't find an option that configures this:
You can have it load the image at boot when kernel level drivers are being loaded, yes. It increases boot time, but user-level processes won't load before the RAMdisk is available.

Re: Speeding up a database

Posted: Wed Mar 27, 2019 6:18 pm
by Jaga
It's a setting under "Image Settings" for the Ramdisk called "Load Mode". You can either choose normal load, or delay load. From my past experience with it, normal load will attempt to load the image during boot (right after the kernel-level driver loads), before Windows starts up. Note: it needs to have a Backing Image for this to work properly.

At one point I was using a ~30GB Ramdisk where the backing image was stored on a medium-performance SSD, and it dramatically increased Windows startup times (the amount of time it sat with the spinning circles for Windows 10). That's how I knew for certain that normal load forced the backing image to mount before Windows. And it's the only way to reliably have a page file on a RAMdisk - a delay load setting wouldn't present the page file to Windows when it needed it.