java.lang.IllegalStateException: The database contains changes from a prev

[Cristian Roldan, geändert vor 11 Jahren.]

Hi,
I'm getting this exception :

[12/10/12 10:13:30:490 CET] 00000016 SystemOut O 10:13:30,487 ERROR [server.startup : 2][MainServlet:217] java.lang.IllegalStateException: The database contains changes from a previous upgrade attempt that failed. Please restore the old database and file system and retry the upgrade. A patch may be required if the upgrade failed due to a bug or an unforeseen data permutation that resulted from a corrupt database.
java.lang.IllegalStateException: The database contains changes from a previous upgrade attempt that failed. Please restore the old database and file system and retry the upgrade. A patch may be required if the upgrade failed due to a bug or an unforeseen data permutation that resulted from a corrupt database.
at com.liferay.portal.tools.DBUpgrader._checkReleaseState(DBUpgrader.java:262)
at com.liferay.portal.tools.DBUpgrader.upgrade(DBUpgrader.java:126)
at com.liferay.portal.events.StartupAction.doRun(StartupAction.java:144)
at com.liferay.portal.ee.license.StartupAction.doRun(Unknown Source)
at com.liferay.portal.events.StartupAction.run(StartupAction.java:52)
at com.liferay.portal.servlet.MainServlet.processStartupEvents(MainServlet.java:1306)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:214)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:358)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.init(ServletWrapperImpl.java:171)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.initialize(ServletWrapper.java:1809)
at com.ibm.wsspi.webcontainer.extension.WebExtensionProcessor.createServletWrapper(WebExtensionProcessor.java:98)
at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:1047)
at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:968)
at com.ibm.ws.webcontainer.webapp.WebApp.initializeTargetMappings(WebApp.java:647)


Looking at the java code com.liferay.portal.tools.DBUpgrader._checkReleaseState, there is a SQL sentence that is executed in order to get the Liferay's database state

private static int _getReleaseState() throws Exception {
Connection con = null;
PreparedStatement ps = null;
ResultSet rs = null;

try {
con = DataAccess.getConnection();

ps = con.prepareStatement(
"select state_ from Release_ where releaseId = ?");
...
...
...

If I execute manually the sql sentence "select * from Release_" I get the following output:

RELEASEID CREATEDATE MODIFIEDDATE SERVLETCONTEXTNAME BUILDNUMBER BUILDDATE VERIFIED STATE_ TESTSTRING
-------------------- -------------------------- -------------------------- --------------------------------------------------------------------------- ----------- -------------------------- -------- ----------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 2012-08-27-10.18.05.565865 2012-12-10-00.00.00.000000 portal 6120 2012-07-31-00.00.00.000000 1 1 You take the blue pill, the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit hole goes.
14306 2012-11-19-16.07.27.412000 2012-11-29-12.58.47.956000 wsrp-portlet 110 - 1 0

2 record(s) selected.


I'm sorry it is not properly formatted, so my questions are:

1) Why my Liferay instance does not work or start properly, why I received that exception?
2) Why I have two rows in the Release_ table ?
3) What is the meaning of the first row ?
4) How can I fix this problem ?

Thanks.

[David H Nebinger, geändert vor 11 Jahren.]

Cristian Roldan:

1) Why my Liferay instance does not work or start properly, why I received that exception?

It is what it is. Looks like you tried to do an upgrade to an existing portal database. The upgrade failed, but the release number had been updated. Then you restarted the 6.1 instance and it reported this failure.

2) Why I have two rows in the Release_ table ?

The second one is for the wsrp portlet. The release table can be used by any plugin, not just the Liferay portal.

3) What is the meaning of the first row ?

This is the version of Liferay the database is for. It is saying 6120 which is the version for 6.1 GA 2. The quote from the Matrix is used to determine if the database supports case-insensitive queries or not.

4) How can I fix this problem ?

Roll back your database to the backup you created before attempting the upgrade and try the upgrade again.

[Cristian Roldan, geändert vor 11 Jahren.]

Hi David,
We did not do any database upgrade, but we had for testing purpose a community edition on the same box, I think both editions were using the same porta-ext.properties file, so propably both were using the same datasource.

Thanks.

[Sam Shi, geändert vor 11 Jahren.]

Hello There,

We have similar situation. We just want to clean up the database for the failed installation and be able to go on for a new installation into the same Oracle Data source. Please help us to uninstall the incomplete old installation.

Thanks,
Sam

[Konstantin Chudinov, geändert vor 10 Jahren.]

Sam Shi:

Hello There,

We have similar situation. We just want to clean up the database for the failed installation and be able to go on for a new installation into the same Oracle Data source. Please help us to uninstall the incomplete old installation.

Thanks,
Sam

I also have the same issue! I can't delete and create new schema and must keep with current one! I've deleted all users tables, but it is not enaugh. What I've missed? Please anybody help!

[Daniel Tyger, geändert vor 10 Jahren.]

Hi All,

I have been fighting the upgrade matrix as well and have some help for you:

If your Verify processes fail during upgrade, you might be able to still boot up by hacking the release_ table with some "good" entries with something like this (for 6.1GA3):
update release_ set buildNumber=6102,state_=0,buildDate='2013-08-02 00:00:00',verified=1,releaseId=1 where buildNumber=6006
(when upgrading from 6.0.6)
and
update release_ set buildNumber=6102,state_=0,buildDate='2013-08-02 00:00:00',verified=1,releaseId=1 where buildNumber=6102;
(if you are re-running verify process after getting Liferay to boot up...)

Trick it to thinking verify went well (1) and state_ is GOOD (0), matching buildNumber, etc...

and

as David said about portlets - remove them from /webapps and they won't bother you as you work out the Verify kinks
OR delete them from release_ as well:
delete from release_ where ...

Hope this helps others. I have been through a lot and this helped me...

[David H Nebinger, geändert vor 10 Jahren.]

Oh, I don't know I'd go so far as 'faking' a good release...

Part of the upgrade process includes applying DDL changes and sometimes actual data manipulation (encoding changes, permissions version changes, etc.).

Faking a 'good' release may lead to other failures down the road...

[Daniel Tyger, geändert vor 10 Jahren.]

David H Nebinger:

Oh, I don't know I'd go so far as 'faking' a good release...

Part of the upgrade process includes applying DDL changes and sometimes actual data manipulation (encoding changes, permissions version changes, etc.).

Faking a 'good' release may lead to other failures down the road...

David - Agreed, thank you - but it did provide a bit of hope / temporary relief, and some tangible insight as to what made it through and what did not...what was working, what was not post the upgrade / migration attempt. I was able to continue my efforts with renewed hope of eventual success...trying to identify the kink...

[Vishal Srivastava, geändert vor 9 Jahren.]

Hi All,

I tried to Migrate from Liferay 6.1.2 GA3 to 6.2 GA2.
While the process i gave DB entry same as older version in portal-ext-properties file.

Know i am facing similar issue and after check my DB Release_ table i found-:
'1', '2014-05-23 17:18:05', '2014-10-09 15:02:18', 'portal', '6201', '2014-10-09 15:02:18', '1', '0', 'You take the blue pill, the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit hole goes.'

Know this table contains entry for Liferay 6.2 GA2. And when i am trying to run my tomcat through Eclipse Run As- it shows me erro-:
Attempting to deploy an older Liferay Portal version. Current build version is 6201 and attempting to deploy version 6102.
java.lang.IllegalStateException: Attempting to deploy an older Liferay Portal version. Current build version is 6201 and attempting to deploy version 6102.

Can you guise help me out that how can i revert my changes back. DO i need to update Release_ table?

Thanks in Advance.

[David H Nebinger, geändert vor 9 Jahren.]

No, you cannot ever move backwards. The release entry is just the tip of the iceburg, upgrades typically do table modifications, column adds, etc.

The only way to use 6.1 again would be to restore the DB and the data directory from a backup.

[Raju oukanti, geändert vor 9 Jahren.]

Hi Daniel,

I successfully migrated my portal from liferay6.0.6 to liferay6.1.2 ga3 version by following your suggestions.But when i am migrating from liferay6.1.2 ga3 to liferay6.2 ga3 i am failed due to tomacat is shut down automatically after migrating the data from 6..1.2 to 6.2 .I have few questions

1. What is the build number for liferay6.2 ga3 i have to place in the release_ table.
2. Why the tomacat is shut down automatically.
3. I have two more entries in the release_ table related to sevencogs theme and market place portlet.What does these entries mean.

Plesae reply ASAP.Please provide the update query related to release_ table w.r.t liferay6.2 ga3 edition.


Thanks,
Raju

[David H Nebinger, geändert vor 9 Jahren.]

1. you shouldn't do because...
2. it shuts down due to a serious failure during the upgrade process with your data.
3. they are release version numbers for other plugins (the sevencogs theme and the marketplace portlet). Don't mess with them.

Track down the issue in your data and resolve it. Trust me, faking out the upgrade should not be your first step when the upgrade fails.

[Raju oukanti, geändert vor 9 Jahren.]

Hi David,


Thanks for giving quick replay.I will come back to you with error which leads to fail my up gradation process.

Thanks,
Raju

[Raju oukanti, geändert vor 9 Jahren.]

Hi David,

Please provide steps to follow when migrating from 6.0.6 to liferay6.2 and also liferay6.1 to liferay6.2.We are not able to find the errors which leads to upgradation fails.It will killing the developers time.Please help me ASAP.

Thanks,
Raju

[Daniel Tyger, geändert vor 9 Jahren.]

Raju oukanti:

Hi David,

Please provide steps to follow when migrating from 6.0.6 to liferay6.2 and also liferay6.1 to liferay6.2.We are not able to find the errors which leads to upgradation fails.It will killing the developers time.Please help me ASAP.]

As David mentioned, you need to identify, then address your issues as they occur. I can tell you I probably re-tried my upgrades over 100 times as new / different errors would surface as the upgrades progressed.

My story is a bit unique in that after I carved out a CE migration path (w some aforementioned hacks to get around Verofy Process failures), I ended up with very similar working data in the end as when we went through a sanctioned, Liferay 6.2EE migration process. It may have been a lot of chance circumstances resulting in a near-perfect upgrade (I lose ~ 20 documents to of 9K in the end)

One thing that has helped us is we decided to delete all users (via Liferay API) except those that hold roles above Site Member prior to the upgrade procedures... This helped remove many thousands of resource permission (and many other, e.g. layout) records. The upgrades were more manageable to analyze and iterate after that process was run before any upgrade attempts. Also, as a tip, I ran permission 6 algorithm upgrade on my 5.2/3 data before migrating to 6+...

Please share error logs / messages if you'd like specific advice (Legends like David can interpret them pretty quickly...)

-daniel