Migration from 7.1.1 to 7.1.2

, ,
1

Hi,

I’m in the process of upgrading from 7.1.1 to 7.1.2. We were able to do a fresh installation, but I’m worry about the process instances and queue tasks that are currently running on our production environment. So before committing to a “dangerous” upgrade in our production environment we did the following:

  • Copied our development webMethods database and restored it with a different name in our development machine.

  • Created a clean Red Hat Linux 5 machine and installed the 7.1.2 from zero, but using our new copied database.

  • Executed the scripts that migrate database components:

  • [LIST]
  • Ex. MWS à
    [/LIST]


dbConfigurator.{bat|sh} -a migrate -d {oracle|sqlserver|db2luw}

-c MyWebMethodsServer -v latest -l db_server_URL -u existing_db_user -p password

-fv 20

The problem is that when we tried to start MWS the following error appears:

2009-07-29 05:19:42 AST (Framework : FATAL) - [POP.005.0021] Attempting to use non empty My webMethods Server database for fresh deployment. Please make sure to create new empty My webMethods Server database
com.webMethods.portal.PortalException: [POP.005.0021] Attempting to use non empty My webMethods Server database for fresh deployment. Please make sure to create new empty My webMethods Server database
at com.webMethods.portal.system.boot.PortalBootManager.verifyPortalBoot(PortalBootManager.java:72)
at com.webMethods.portal.system.boot.PortalBootManager.init(PortalBootManager.java:47)
at com.webMethods.portal.system.init.impl.DefaultPhase$InitializableWrapper.init(DefaultPhase.java:118)
at com.webMethods.portal.system.init.impl.DefaultPhase.initComponent(DefaultPhase.java:99)
at com.webMethods.portal.system.impl.BaseProvider.initComponents(BaseProvider.java:512)
at com.webMethods.portal.system.impl.BaseProvider.init(BaseProvider.java:125)
at com.webMethods.portal.system.init.impl.DefaultPhase.init(DefaultPhase.java:44)
at com.webMethods.portal.system.init.impl.DefaultPhaseProvider.initComponent(DefaultPhaseProvider.java:257)
at com.webMethods.portal.system.impl.BaseProvider.initComponents(BaseProvider.java:512)
at com.webMethods.portal.system.impl.BaseProvider.init(BaseProvider.java:125)
at com.webMethods.portal.system.init.impl.DefaultPhaseProvider.initializePhases(DefaultPhaseProvider.java:89)
at com.webMethods.portal.system.init.impl.ClusterPhaseProvider.initializePhases(ClusterPhaseProvider.java:27)
at com.webMethods.portal.system.PortalSystem.init(PortalSystem.java:868)
at com.webMethods.portal.system.PortalSystem.main(PortalSystem.java:827)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.webMethods.portal.system.start.Main.start(Main.java:131)
at com.webMethods.portal.system.start.Main.main(Main.java:48)



What should we do to fix this?


Thanks

2

Did you find a way to fix this?

–Meena

3

If you install a new instance of MWS, it would need a fresh DB to start with.
This is because, MWS extracts its runtime data into the DB and this is specific to each instance.

So you either:-

  1. Migrate to higher MWS version using the Upgrade guide
  2. Create a fresh MWS instance and run it on a empty DB schema.

Does that answer your question?

Thanks
Dev

4

Task runtime data can also be migrated. Advantage has an article on it
Using the Tasks migration portlet (Administration->Admin Dashboard->Migration) will move task instances from one MWS to another once they are running. (After you deploy the task applications)

As stated above you need a new instance of MWS pointing to a fresh DB.
This means a new
• Database user name AND
• Database name or tablespace name

If you change the tbl space name remember to do update all scripts.

Tip: mws new -Dserver.name=INSTANCENAME … if you don’t type instance name it will use Default (Which is the one already in use unless you changed it originally).

Upgrade documentation is good and worked for us when we did 7.1 → 7.1.2

I just had do this myself due to a corrupt user which is referenced in a table “somewhere” where “somewhere” is undocumented. So I did a migration one instance to another same version :slight_smile: