File size tripled overnight

[Jeckles]

Hello,

We are running an FM15 solution on a Windows Server platform in a small sized company setting.

The FM solution is comprised of about 70 Tables, multiple layouts and Scripts.

Its been in use for over 6 years in this environment and working well

On June 25th, the File size grew from 1.7 GB to 5.8 GB

Performance the next day was fine, and we actually didn't notice the change until 2 weeks later

I have run:

File/SaveAs/Compacted: 4.29 GB

Save as Clone No records: 3.24 GB

I have run the DDR report on an older,smaller backup file and this one and cannot detect any glaring differences

When running the Recover command it hangs on recovering the last Library, (has no name?) at around 4514. I saw this in the Recover Log file

I have tried systematically deleting tables, layouts but the file size does not diminish by much

I'm afraid since the recover does not finish, I am looking at some corruption.

Does anyone have any other trouble shooting ideas or why the file size may have grown?

Any comments are appreciated

Jon

[Wim Decorte]

3+ GB for a file with no data (clone) is huge and not typically normal.  Do you use a lot of layout elements like pictures or graphics?

Try to produce an XML DDR report, if it does not finish then the place where it stops could be a good indicator of something that is off in the and it will point you to where that is (you'll need to backtrack the XML structure from the point where it stops, so it is a bit of chore).

Don't run recover on your original file, run it only on copies or backups!

Also look in the FMS event log to see if FMS crashed at some point.  If you are running FMS on Windows, also use the Windows application event log and system event log to look for errors.

[Fitch]

I had a similar experience, not quite so drastic, where a file was growing something like 100 MB/day. But it was an interface file where no data was being added.

To troubleshoot, I took a copy of the file and since, as you discovered, cloning doesn't fix it, and deleting fields didn't fix it,  I started deleting tables, then closing the file to see the effect on file size. If you have a lot of tables you can hone in on the culprit by deleting half of them, check size, if no change, delete half of remaining, etc.

It turned out deleting one particular table made a difference. Even though it supposedly had no data. Then I had a thought -- what about the truncate script step? It worked! Whatever was lurking in that table -- presumably something in a container -- was flushed out by truncate.

Good luck and welcome to FM Forums.

[Jeckles]

Thank you to both Wim Decorte and Fitch for your replies.

There are several layouts with some graphics used for printing of reports, I have tried deleting these layouts but not much change in file size.

Our biggest file use is a container field for documents, but it is stored in a separate folder on the server.

I did run the DDR on both an older backup, and a backup of the big file (definitely, I am working with a backup of the file in question) The DDR on the file in question (big file) ran with no problems. Comparing the 2 DDR's did not show me much.

I think I will continue Fitch's approach and continue deleting Tables and layouts in sequence and see if I can find the culprit. Its interesting to note that your culprit was a table with no data.

I had our IT Hardware person look at the logs on the Window server, and we see it jumped in the middle of the night of June 25th. I will ask him to verify if the FM Serve crashed and possibly auto-restarted.

Thank you again for your replies. Very Helpful.