We deal with the hardware by lot of different cases - when someone ask us what to buy for the new server, how to improve existing hadware, and, of course, when database becomes corrupted.
Many hadware vendors (as we see) sell servers with ready to use RAID (1, 5 or 10), with operating system installed on that raid. Also these hardware vendors think that it is cool that customer will place everything else on that RAID, and it will work perfectly (long and stable), so, no additional disks. That common mistake leads to real pain if something happens with the RAID.
Well, if you had your database on the RAID, and it fails, you need to find latest backup, and restore from it (after repairing RAID, of course).
But, if there were operating system on that RAID, it becomes a bit more complicated.
10 minutes ago we had a request to repair database from the RAID, broken by it's controller fail. The database is a real mess, so, sorry, there is nothing left to repair.
I don't know, was there also operating system, or not, but if it were:
- Your server failed, and it can't boot. You can't understand what happened with RAID.
- You need to attach additional HDD to server, install operating system on it, boot, then install RAID drivers and RAID software.
How much time it will take?
Well, let's put operating system on separate drive. RAID failed? Well, ok, but we can boot and look at RAID state.
You have doubts about that hard drive reliability? Make image backups. OS does not occupy much space - such an image can be stored even on flash-drive.
Ok, someone will say - yes, I will separate OS and my data. But I still want to keep OS on RAID 1, for reliability. Of course, it will protect OS from single disk failures, but, if RAID controller will fail, we will be at the starting point of that story.
Thus, my opinion is to have cheap (or not) and one (!) HDD for OS, that can be changed in a few minutes, and can be bought in any computer store nearby.
This solution, in spite of cheapness, can save lot of time in case of failure.
Think about it. Don't rely on "cool expencive RAID". Be a bit paranoid. :-)
Tuesday, September 06, 2011
Wednesday, March 23, 2011
no_garbage_collect
You do not know what is that? Well, InterBase and Firebird allow specifying connection parameter that will disable garbage collection by statements in this connection.
This is the same as the option -g for gbak. And, of course, all other connections without this parameter will continue to try collecting garbage in the database, if any.
This connection option mostly is not known, because standard and "closed source" drivers usually does not produce access to server-specific features. Thus, you may use this option only for IBX (IBExpress components in Delphi and C++Builder), FIBPlus, and some other "direct access" components. ODBC, dbExpress? No, of course.
But, why you may ever need this option?
Sometimes you may want to run huge report that will scan lot of data. And, at the moment this report will run, there may be lot of garbage record versions in the database. So, your report connection will collect garbage (especially if you use Firebird Classic), and report will run much slower than it could be.
In this case, before running the report, you may set no_garbage_collect option, and report will be fast as a rocket.
I also knew some small applications with small databases (up to 1gb), that used no_garbage_collect option for all connections. This way garbage is not collected at all, and during the day size of database could grow 2 or 3 times. But, each day database was scheduled to backup and restore, so, why to care about garbage?
Since I do not see needs to do backup and restore each day, I do not recommend disabling garbage collection this way. Use it only for specific connection, if you ever need to do this at all.
This is the same as the option -g for gbak. And, of course, all other connections without this parameter will continue to try collecting garbage in the database, if any.
This connection option mostly is not known, because standard and "closed source" drivers usually does not produce access to server-specific features. Thus, you may use this option only for IBX (IBExpress components in Delphi and C++Builder), FIBPlus, and some other "direct access" components. ODBC, dbExpress? No, of course.
But, why you may ever need this option?
Sometimes you may want to run huge report that will scan lot of data. And, at the moment this report will run, there may be lot of garbage record versions in the database. So, your report connection will collect garbage (especially if you use Firebird Classic), and report will run much slower than it could be.
In this case, before running the report, you may set no_garbage_collect option, and report will be fast as a rocket.
I also knew some small applications with small databases (up to 1gb), that used no_garbage_collect option for all connections. This way garbage is not collected at all, and during the day size of database could grow 2 or 3 times. But, each day database was scheduled to backup and restore, so, why to care about garbage?
Since I do not see needs to do backup and restore each day, I do not recommend disabling garbage collection this way. Use it only for specific connection, if you ever need to do this at all.
Subscribe to:
Posts (Atom)
