This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

New FMS setup for changing the DB type

Hi,

 

We are planning to change our database type from Oracle to MSSQL.

And we are talking this opportunity to upgrade the FMS version also.

 

To achieve this we are completely uninstalling old FMS(version 5.6.11) and reinstalling the new FMS(version 5.7.5) in the same server.

 

I have few question here could anyone please answer this please?

  1. We want to import all the customs rules and dashboard to new FMS. What is the best way to do this? Is this possible with different version of the FMS?
  2. After the installation will all the old Agents will connect back to the new FMS?

 

Can guide me what are all the other steps I need to consider here?

 

 

Thanks,

VML

  • Hi,

    That is a great question and something we are considering ourselves.

    The main question for us is how to transfer the historical data from our Oracle database to a SQL Database so we don't lose data and metrics that we might wish to report on.
  • Hi,

    Thanks for reply!

    As this is a very urgent requirement for us, we are not worrying about historical data.
    I am just thinking about custom rules, reports and dashboard. and reconnecting back of exiting agents.

    i want to know correct method to do it.

    Thanks,
    Vivek
  • and since we are changing the FMS version will export and import of Rules, Report and Dashboard will work? or do we need a same version of dashboard?

    Thanks,
    Vivek
  • Hi Vivek,

    Having created new FMS's and connected them to the same Oracle database or a clone of the database on a different server I can confirm that all of the data, dashboards and rules functioned correctly under the new FMS however all of the relevant cartridges needed to be installed to get everything working again.

    I think the main thing would be to figure out how to convert the database from Oracle to SQL. That should reduce the amount of work you will need to do later.

    If it is really urgent then it may be a suggestion to go ahead and build the new FMS and database and get things monitored, then worry about the customisation later and importing everything. Sometimes it is nice to start with a clean slate.

    Connecting the current FGLAMs to the new FMS is simple and just requires changing the FMS upstream connection in the fglam.config.xml file under %FGLAMHome%/state/default/config/

    Have you raised a support call with Dell or Quest?
  • On a further note, I have just submitted a Service Request with Dell Support so hopefully will have an answer soon.
  • Hi,

    Thanks for that!!

    i had raised case but support told me that they will not support for changing the database type from one to another (Oracle to MSSQL), so i came up with this idea using fresh installation.

    My only concern was exporting dashboard which were present in this present version(5.6.11) to newer version of the FMS(5.7.5), because in this KB article it is mentioned like that support.software.dell.com/.../39370. but now you cleared my doubt, thank you for that.

    And connecting back the FGLAM to FMS i think i don't need to do anything since we are installing the FMS on the same server.
    we are installing the FMS on same server - we are stopping the present FMS and installing the new FMS on same server, so we dont need to make any changes on FGLAM side, correct?


    Thanks,
    Vivek
  • Hi Vivek,

    I think we have our answer then.

    The FGLAMs are separate entities and specific to the type of server you have them installed on. Providing the FMS is installed on the same server you should be fine. If you installing the latest version of the FMS then the only problem I can see is that you may have to manually update the FGLAMS to the latest version as well if they do not connect to the FMS straight away. If they connect then you should be able to upgrade them from the Agent Managers dashboard once you have installed the latest cartridge.

    In fact, in the latest updates of the cartridges the groovy script on the rule conditions have been updated and a lot of the rules and rulettes have been improved. Whenever I upgrade a cartridge I normally check the new rules in the cartridge against the custom rules I have set up to check for these improvements.

    After a discussion with my team, we are going to continue to look at upgrading but over a long period. Effectively using the current linux based FMS as a backup and for reporting for historical purposes. We will have to work with a fresh clean install as well.

    One of my concerns with dashboards is that I create dashboards using the Service Builder as a base. If you do this as well you may end up having to recreate a lot of dashboards anyway.

    This upgrade is going to be a massive undertaking. Keep me posted with how it goes.
  • Actually thinking about it the beauty of your upgrade is that it is on the same OS based FMS and its only the database that's changing. I would suggest creating a separate instance of the FMS to connect to what would be the old database if you have the scope to do so for historical purposes, but if the historical data is really not required then go ahead.
  • Hi Vivek, I'm completing an 8.4 to 8.5 upgrade. I will attempt to figure out how to post my multi-stage procedure here or somewhere in the next week or so. The Foglight upgrade documents are thorough but I sorted thru them for stuff relevant to me plus other items. I did not change the DB targets as you are considering. I do agree that greenfielding on a new version might be the best way to move forward. It will also give you a chance to fully document the setups. Keeping the former version online will be useful to compare as well. Cheers, Gregory Mobley

  • Hi Vivek,

    Latest response from Quest on Support for changing hardware is to use the following kb article.

    support.quest.com/.../56684

    This doesn't mention anything to do with database migration however so I think we are both going to be stuck with using the old FMS and database as a backup for historical reporting.