(I've read a lot about 64-bit versus 32-bit OS/Apps, but this question is specifically in regards to databases.)
I'm trying to understand the pros and cons of 32-bit versus 64-bit databases, and namely, under what conditions that it starts to make sense to use 64-bit installations.
The database systems that I am interested in are: SQL Server 2008, MySQL, and PostgreSQL 9.0.
I have read that pre-9.0 versions of PostgreSQL only comes in 32-bit for Windows, and this article about running 32-bit PostgreSQL on 64-bit Windows clears up some of my confusion, but I'm looking for more info.
When would I benefit from using 64-bit databases (i.e. database size/disk space, available system memory, types of data sernarios that are known to benefit from it, which database engine being used, etc.)?
Assuming you have a 64-bit capable OS and processor, the most important advantage of 64-bits is the ability to use more than 4GB of memory.
Related
I was wondering to install a server on my windows machine and came to know that it is best to install a 32bit version on a 64bit machine. Is it really required.
Why is it recommended?
I want to install it for study.
Installing 32-bit software on a 64-bit machine is not recommended. No one with any credibility would make this senseless recommendation.
A major disadvantage of 32-bit software is that it cannot use more than 4GB of RAM, because memory addresses must fit into the word size of the software. This is a serious deficiency for a database server, which benefits from extra RAM.
I did consulting for a major company who was having database performance trouble. They were using Windows Server. They had been adding extra RAM DIMMs, having heard that RAM can be used to increase caching resources, but no matter how much RAM they added, it didn't help.
I logged into their site and found they were using Windows Server 32-bit. They had been spending a ton of money on RAM, but their operating system could not see it.
I listened to the YouTube video you linked to, to hear the justification of the speaker. He seems to be saying that since Windows 64-bit is backward-compatible and can run 32-bit binaries, but the reverse is not true (Windows 32-bit cannot run 64-bit binaries), he thinks you should use 32-bit binaries because they will work on both architectures.
That's bad advice.
The better advice is: Make sure you aren't using Windows 32-bit.
Come on, it's 2018. The days of 32-bit platforms is long gone.
It is definitely not required. I would say that it's not even recommended. Any 64 bit machine will be able to run a 32 bit server, however, a 32 bit server will highly underutilize the processor, especially when performing complex or graphical operations
We are running Windows Server 2008 R2 (64-bit), SQL Server 2008 R2 (64-bit) and a 32-bit Java application all on the same server. The application uses the Microsoft JDBC Driver v3. The application can use Java 5 or Java 6, but both as 32-bit JRE's. So the driver can be type 3 or type 4.
Here's what we see: When the application runs, database access can become quite slow when under any type of load. When you remove the load, it will be okay. Put it under load again, and it becomes slow.
The complex part of this is: If we run the application on a separate but equal server from the database, it is not slow.
So it appears that the behavior of the driver is different. When driver and database are on the same server (reached through the local stack), then the mix of 32-bit and 64-bit slows things down. When the driver and database are separate from each other (reached through the network), then the mix does not cause a slow down.
Any thoughts?
We do not expect the application and database to be on the same server. But we have sales people who demonstrate on a single laptop, so they need it all together. Currently, we look like we will be forced to isolate using VM's or similar. Not what sales wants.
Technically, we are curious why introducing the network makes a difference.
I was wondering if it was possible or is there a way of using that all together on one machine without virtualization
I don't think so. The only option for running Windows apps directly would be something like Crossover but SQL Server is known not to work with Crossover (or WINE on Linux for that matter).
Unlike typical Windows apps, SQL Server is likely to be deeply integrated with the OS for operations like disk access, etc.
With enough memory, virtualisation is probably the best way to go - you should be able to access the 'remote' virtualised database easily enough.
Can MySQL 5.4 beta be compiled for 32-bit processors under Linux?
The current beta only has binaries for some 64-bit versions, but if you're keen on starting to beta test right now you should be able to compile from the sources on a 32-bit systems. (It IS a beta, of course, so unreliability IS to be expected -- don't run it in production, whether on 32-bit or 64-bit systems!)
According to this blog it's only available for 64-bit machines.
http://willysr.blogspot.com/2009/04/mysql-54-preview.html
or here
First, the preview release of MySQL
5.4 only includes the InnoDB scalability fixes (addressing more
CPU's/cores). Second, it is limited to
the Solaris and Linux 64-bit platforms
at this time. The other features
mentioned in this article and
additional platform support will be
appearing very shortly, so be looking
for upcoming announcements soon.
http://74.125.93.132/search?q=cache:iLgUTcXAmGUJ:mirror.facebook.com/mysql/tech-resources/articles/mysql-54.html+mysql+5.4+64bit+only&cd=9&hl=en&ct=clnk&gl=us&client=firefox-a
google cache because that website is down
if you can run ./configure and make without any errors, it should work properly.
Microsoft has chosen to not release a 64-bit version of Jet, their database driver for Access. Does anyone know of a good alternative?
Here are the specific features that Jet supports that I need:
Multiple users can connect to database over a network.
Users can use Windows Explorer to copy the database while it is open without risking corruption. Access currently does this with enough reliability for what my customers need.
Works well in C++ without requiring .Net.
Alternatives I've considered that I do not think could work (though my understanding could be incorrect):
SQLite: If multiple users connect to the database over a network, it will become corrupted.
Firebird: Copying a database that is in use can corrupt the original database.
SQL Server: Files in use are locked and cannot be copied.
VistaDB: This appears to be .Net specific.
Compile in 32-bit and use WOW64: There is another dependency that requires us to compile in 64-bit, even though we don't use any 64-bit functionality.
Luckily, things have changed in the past two years:
Since Office 2010 is available in a 64-bit version, Microsoft had to create a 64-bit version of their Jet Engine. According to the Microsoft Customer Service blog, the Microsoft Access Database Engine 2010 Redistributable contains a 64-bit driver, which is able to access recent versions of the Microsoft Access database format.
Users can copy the database while it is open without risking corruption.
You can't do that with any database file with multiple users and/or processes modifying it.
What you're looking for is SQL Server Express with the portable .mdf files. To get around the copying limitation you need to make sure that the software in question doesn't keep connections open (i.e. create a disconnected data access layer).
Try to have a look at http://www.vistadb.net/
#Orion: Agreed, OP would be advised to go with SQL 2005 Express (if possible). The deal breaker is being able to copy the DB while in use/attached which is out of the question with SQL without using some kind of backup tool that can copy 'in use' files.
Another way would be to automate a backup and restore to roaming machine but this is getting a long way away from being able to just grab a copy of the file.
Another alternative you can look at is SQL Server Compact Edition (CE). I believe this has 64bit binaries.
I also agree with Orion and Kev about the copying the database.
What I am going to do is to create a separate 32-bit executable that connects to Jet that my 64-bit application can communicate with through COM.
This satisfies my general requirement of "work like Jet", because it is Jet. My customers don't get the benefit of 64-bit, but the other requirements are more important.