MAC OS X System Crashes

[Rob Tito]

Hi All.

Sometimes when running FMP and your system crashes it leaves you with a corrupted database.

When the faults aren't severe you get the "checking for unused blocks" window the next time you try to startup the database.

For a file of around 50 GB that will take about one hour so thats pretty much ok.

(It takes longer to restore a backup of the file)

If the errors are more profound you are prompted to RECOVER the file.

Now here is where the sh*t starts.

In my notion any databasefile extending about 2-3 GB trying to recover from a crash results in an "unable to recover" message.

So far I have circumvened this by keeping some backup copies of the database and refresh them daily.

Nw the question: what is your experience with this phenomenon.

I stopped using recover for large (>2 GB) databases since version 4 or so.

Recovering 4-10 GB takes about 24 hours and end up messaging you: unable to recover file - thus a waste of time.

What are your impressions and experiences with database crashes?

TIA

Rob

[Ender]

What are your impressions and experiences with database crashes?

I try to avoid them. : I'm being funny, but also serious. You should not be having stability problems that cause unexpected closure of files, and you should work to solve those stability problems.

If you're not already, you should be using Server 8 to host those large files. It does a much better job of managing large files and a large number of clients, than using a FileMaker client to host. It also has automated backups, which is the next line of defense, should a crash happen.

If you can say more about your setup, we might have further suggestions. Specifically, the OS version, computer model and speed, RAM, hard drive type, backup methods, number of clients, FileMaker host & client versions, number and size of files being hosted, cache setting (if using FM Server,) and any other programs running on the host. Also, is there anything that seems to cause the system crashing?

[LaRetta]

When the faults aren't severe you get the "checking for unused blocks" window the next time you try to startup the database.

And are you aware that your file can still be corrupted? How do you KNOW it wasn't damaged? Even FM can't determine (for sure) whether there was damage. If I EVER get the scanning error on a file (hosted file closed unexpectedly), I trash the file. And a file which has crashed once is prone to crash again. Call me paranoid...

[D-fendr]

Which version of 8 Server are you using?

I was needing to upgrade soon, but the bug notices for 8v2 scare the dickens out of me.

Have you read them and, if so, do you not perform any functions listed in the bugs?

thanks,

[Ender]

I'm using 8v2 because it fixed some stability problems with a large number of clients. The change in behavior of Finds on unstored calcs is definitely an issue, but having to deal with that is better than having the server hang when things get busy.

[D-fendr]

Thanks. One system is too large to convert without a lot of work checking the finds glitch.

The other is relatively small app, all single users with one exception of a two person network. It's on 8v1 now and just releasing.

I wonder if you or anyone knows more about this:

-------

Issues in FileMaker 8.0v1 products:

*

Some calculations that require local client information (such as Get(WindowHeight)) are incorrectly calculated on the server. There are no known workarounds in this version.

*

Certain batch operations and schema changes might cause indexes to become corrupt. These indexes can be rebuilt via the Define Fields dialog box by turning the index off, and then on again.

-------

Is there more information somewhere on just what client Gets (or all) are affected, what "batch operations, etc?

d

[Ender]

I don't know. I never saw any issues, and I don't use get(windowheight) for anything.

[xochi]

Hi All.

Sometimes when running FMP and your system crashes it leaves you with a corrupted database.

Whoa, stop! It sounds like you are having frequent crashes, and that you think this is OK. It's not ok, you should figure out what's wrong with your system and stop the crashes.

My expectations for a serious database would be (A) that I'm running on FileMaker Server ( that fileMaker Server, and the machine that its running on NEVER crash, and that © if fileMaker Client (or the machine it's running on) do crash, no harm comes to the database.

Alas, FileMaker and Apple have had some problems along the way, and back in the FileMaker 5/6 days, I did have the expectation that crashes were the norm. But in the 7/8 era, thy are not, and you can set your expectations higher.

Read this thread for my experiences with stable filemaker / OS combos: http://fmforums.com/forum/showtopic.php?tid/173061/

[Rob Tito]

I didn't mention frequency, I only noted that when you experience a kernel panic aka core dump it renders you in the majority of the cases with a corrupted database.

Only option left then according to opening the file again in filemaker is recover.

Well that doesnt work too wel if not not at all.

That was where my remark was about.

Rob

[HumblePie]

I have found that going to the last known uncorrupted backup, creating a clone and re-importing (over a weekend probably) is the only way to be absolutely sure. A less extreme solution is to recover BEFORE being prompted. This rebuilds all indexes just for starters. But appears to do other good besides.

Don't bother with file maintenance if you are uncertain as to the integrity of the file, by the way.

In my opinion, corruptions are rather better diguised in the .fp7 format. You can continue for a while before they rear their ugly head.

They can be caused by any complex relational process like a non-indexed search or calculation, so it is REALLY important to be sure of all of your TOs and predicates, that they are sound and indeed necessary.

Is this solution still being "developed" from time to time as well or is it simply being "used"?

[xochi]

I didn't mention frequency, I only noted that when you experience a kernel panic aka core dump it renders you in the majority of the cases with a corrupted database.

Hi Rob,

Ugh, I see your issue.

Kernel panics on a server system suggest a hardware problem (bad RAM or failing Hard Disk), or a really screwed up system software install, or (my personal bugaboo) power issues, such as brownouts of very brief blackouts. I once had frequent database crashes & corruption which I finally traced to power problem in my office. A UPS solved that.

These days, your expectation should be that your server never crashes unless some hardware actually fails.