Skip to main content
  • EN
Hi,

 

 

We are about to implement FME Server for our Organization...As the business owner for the application (we will likely also be the administrators), our preference would be to use the FME Repository database delivered with FME Server. Unfortunately our IT group has a policy for using Oracle for all applications.

 

I am trying to defend our position of going with the default database.

 

Does anyone have experience with and or recommendations about which FME Server repository to go with  between Oracle and the built in db?

 

 

Does anyone know why FME Server supports external database repositories...it seem to just complicate the installation and I can't see any upside?

 

 

The reference Manual simply states the following and there is not much more detail in the Admin Guide 

 

 

"The FME Server Core uses the repository database to store job and repository information. The database should never be edited directly, although querying the database for job history and other statistical information is common.

 

FME Server comes with a default database, and we strongly recommend that you use this database. However, PostgreSQL, MySQL, Oracle, and SQL Server are also supported, if there is a compelling reason to use them."

 

 

I guess I'd like to know if anyone has ever used one of the 'other' supported databases and understand what the compelling reason could be?

 

 

Thanks FMEr's

 

Just some history:

 

Before FME Server 2012, a light-weight HSQLDB database was used which was not recommended for production usage. As a result, Safe made it so that you could utilise other databases instead.

 

 

In FME Server 2012, they have switched over to using a PostGres database in the backend by default. Yet, they also allow other databases for versatility and backward compatibility reasons.

 

 

PostGres is much more powerful than HSQLDB, requirs less configuration changes and is packaged within FME Server thus giving an out-of-the-box solution.

 

 

Some examples of reasons to use a non-default database may include:
  • Integration into an existing DBMS environment (centralisation purposes, security purposes, etc)
  • Corporate policy
  • Preference of a DBMS for ease of statistical querying
  • Ease of backup
Hope this helps!
Thanks  1SpatialKathy!!

 

 

Your answer helps quite a bit.

 

 

It raises some other question around administration of the default database:

 

 
  1. Are there specific administration activities that need to be performed directly on the database that cannot be performed using the FME Server GUI.
  2. If there is either an application or database critical failure - are there recommended restore procedures specific to the database?
  3. Can the database be restored from a tape backup if the full FME Server installation is reinstalled?
  4. What other backup procedures, if any, are recommended for the default database?
  5. Can the FME core application be reinstalled without overwriting the default database?
  6. Finally, would it be fair to say that Safe software recommends use of the default db because it simplifies their support for the product?

Hi Mike

 

 

As far as I remember, Safe even recommended to use an extrenal DB at the times of HSQLDB ... My 5 cents on an external DB:

 

 

I prefer to control that myself, so I do use it (normally as well PostgreSQL, however my own one). One reason: I like to dig into it .-) ... as long as you know what you ar doing, it is not a problem

 

 

To your quetsions.

 

1. not really, however I'd do backups

 

2. not that I know

 

3. I think so, however I never tried ... it's a fairly simple bunch of tables, so I do not really see problems there ...

 

4. normal backups should do

 

5. don't know, however you could for sure do a backup/restore

 

6. as said, at the times of HSQLDB Safe even recommnded to use another one

 

 

cheers

 

flavio
We had FME Server running on Oracle for a while. The main reason for us was that we could upgrade FME Server and not lose any of our repository in the process. However, because Safe had a tendency to make changes to the schema during upgrades, it didn't always work out.

 

 

We also found that we were having performance issues with the external DB. Might have been just too much network traffic. Switching to the supplied PostGres DB solved the performance issues.

 

 

Whichever path you choose there will be pain points during upgrades. Safe is working on making the process easier but it's still not seamless.
To add some comments to Flavio's:

 

 

  1. The only administration activity that I would recommend to be done on the database directly is to back it up (if you do not want to use Safe's FFS backup methodology). 
  2. The database holds the logins, repository and job history. In case of a critical failure of the database, you would need to restore the database via the provided FME Server specific SQL scripts, reimplement the repositories from the backup FFS file and reimplement the security logins, roles, etc. That is all in the case that you don't backup the entire database.
  3. Sure it can. The database simply contains the jobs, reepositories, security setup, etc. If you have all this backed up, simply restore away and point FME Server to the database via instructions in the Admin Guide.
  4. The recommended backup procedures are stored in the Admin Guide. Safe suggests to backup the repositories to FFS via FME Desktop for example.
  5. Yes. The database is a separate entity to FME Server. You can reinstall FME Server, put in an Engine or two and the database would be unharmed. Think of a link between the database entity and FME Server entity. If that link is severed due to the uninstallation of FME Server, it can easily be reestablished when FME Server is reinstalled. 
  6. Not entirely sure. However be aware of Nic's comments and take into consideration that the opensource PostGres database is powerful in its own right. I'm sure Safe have ample reasons to recommend a totally out-of-the-box plug-and-play solution rather than separate components everywhere.

Reply


Community Stats

30,147
Posts
114,429
Replies
37,790
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.