Subject | RE: [ib-support] Re: 24x7 |
---|---|
Author | Thomas Steinmaurer |
Post date | 2002-06-08T09:06:39Z |
An additional one.
If possible, temporary (sort) files of Firebird should be
on a different HD than the physical database file.
Just a thought ;-).
Regards,
Thomas Steinmaurer
IB LogManager 2.0 - The Logging/Auditing Tool for InterBase and Firebird
http://www.iblogmanager.com
If possible, temporary (sort) files of Firebird should be
on a different HD than the physical database file.
Just a thought ;-).
Regards,
Thomas Steinmaurer
IB LogManager 2.0 - The Logging/Auditing Tool for InterBase and Firebird
http://www.iblogmanager.com
> -----Original Message-----
> From: mgastde [mailto:michael.gast@...]
> Sent: Saturday, June 08, 2002 10:54 AM
> To: ib-support@yahoogroups.com
> Subject: [ib-support] Re: 24x7
>
>
> Hi Sanjay,
>
> >>We plan to use FB
> >>in 24x7 environments (healthcare)
> >>
> >>Is it safe / recommended ?
>
> We are doing it since a few months. Our experience with Interbase /
> Firebird ist quite good, but you have to mention some important
> points (possibly points are missing in my list):
>
> 1. We were using Firebird Classic Server on a Redhat Linux SMP box.
> About two months ago we got strange errors with corrupt index and
> data pages. We allways could repair the database via backup and
> restore, but the database has actually a size of about 35 GB and
> contains more than 20 millions of records. So backup and restore takes
> a lot of time. We could solve the problem by switching to the Firebird
> Super Server but up to now we do not know exactly what caused the
> errors. I suggest actually not to use a SMP machine.
>
> 2. Ever, ever use the setting FORCED WRITES ON!!!
>
> 3. Running a backup under Firebird is like running any other
> transaction. So a backup contains all data commited at the starting
> time of your backup. Performance is quite fair during backup.
>
> 4. As far as i know there is no(!) redo log utility like in Oracle. I
> would like to have it, but i did not find such a tool. If you need to
> recover your data after a crash to a state after your last backup, you
> have no tool to do this. Start keing in :-(
> I'm currently thinking of realising it by myself, but I'm not a good
> C++ programmer...
>
> 5. Pay attention to the size of your database files. If the one or the
> last file of your database grows over the maximum file size of your
> OS, your database will be corrupted.
>
> 6. Pay attention with sweep. We switched it off. Sweep is now done in
> a low usage time (started with a cron job).
>
> Hope my suggestions will help you.
>
> Best regards
> Micha
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>