Upgrade fails from LR6.1.0-ce-ga1 to LR6.2 CE-GA6

[7年前 に Meenakshi Kandasamy によって更新されました。]

I am new to liferay and trying to upgrade our portal from LR6.1.0-ce-ga1 to LR6.2 CE-GA6 and getting the following error.Can anybody help.

14:11:30,493 INFO [localhost-startStop-1][UpgradeProcess:164] Upgrading com.liferay.portal.upgrade.v6_2_0.UpgradeLayoutFriendlyURL
14:11:30,573 ERROR [localhost-startStop-1][MainServlet:234] com.liferay.portal.kernel.events.ActionException: com.liferay.portal.kernel.upgrade.UpgradeException: com.liferay.portal.kernel.upgrade.UpgradeException: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (PORTALMGR.SYS_C00108915) violated_ [Sanitized]
com.liferay.portal.kernel.events.ActionException: com.liferay.portal.kernel.upgrade.UpgradeException: com.liferay.portal.kernel.upgrade.UpgradeException: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (PORTALMGR.SYS_C00108915) violated_ [Sanitized]
at com.liferay.portal.events.StartupAction.run(StartupAction.java:80)
at com.liferay.portal.servlet.MainServlet.processStartupEvents(MainServlet.java:1246)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:231)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5266)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5554)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:677)
at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1912)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: com.liferay.portal.kernel.upgrade.UpgradeException: com.liferay.portal.kernel.upgrade.UpgradeException: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (PORTALMGR.SYS_C00108915) violated_ [Sanitized]
at com.liferay.portal.kernel.upgrade.UpgradeProcess.upgrade(UpgradeProcess.java:170)
at com.liferay.portal.upgrade.UpgradeProcessUtil._upgradeProcess(UpgradeProcessUtil.java:162)
at com.liferay.portal.upgrade.UpgradeProcessUtil.upgradeProcess(UpgradeProcessUtil.java:114)
at com.liferay.portal.upgrade.UpgradeProcessUtil.upgradeProcess(UpgradeProcessUtil.java:94)
at com.liferay.portal.events.StartupHelper.upgradeProcess(StartupHelper.java:138)
at com.liferay.portal.events.StartupHelperUtil.upgradeProcess(StartupHelperUtil.java:61)
at com.liferay.portal.tools.DBUpgrader.upgrade(DBUpgrader.java:143)
at com.liferay.portal.events.StartupAction.doRun(StartupAction.java:181)
at com.liferay.portal.events.StartupAction.run(StartupAction.java:74)
... 19 more
Caused by: com.liferay.portal.kernel.upgrade.UpgradeException: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (PORTALMGR.SYS_C00108915) violated_ [Sanitized]
at com.liferay.portal.kernel.upgrade.UpgradeProcess.upgrade(UpgradeProcess.java:170)
at com.liferay.portal.kernel.upgrade.UpgradeProcess.upgrade(UpgradeProcess.java:184)
at com.liferay.portal.upgrade.UpgradeProcess_6_2_0.doUpgrade(UpgradeProcess_6_2_0.java:77)
at com.liferay.portal.kernel.upgrade.UpgradeProcess.upgrade(UpgradeProcess.java:167)
... 27 more
Caused by: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (PORTALMGR.SYS_C00108915) violated_ [Sanitized]
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:440)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:396)
at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:837)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:445)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:191)
at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:523)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:207)
at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1010)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1315)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3576)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3657)
at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(OraclePreparedStatementWrapper.java:1350)
at org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
at org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
at com.liferay.portal.upgrade.v6_2_0.UpgradeLayoutFriendlyURL.addLayoutFriendlyURL(UpgradeLayoutFriendlyURL.java:69)
at com.liferay.portal.upgrade.v6_2_0.UpgradeLayoutFriendlyURL.doUpgrade(UpgradeLayoutFriendlyURL.java:103)
at com.liferay.portal.kernel.upgrade.UpgradeProcess.upgrade(UpgradeProcess.java:167)
... 30 more
Stopping the server due to unexpected startup errors


Thanks in advance

[7年前 に David H Nebinger によって更新されました。]

So first of all you want to have a backup of the database and the data directory because you're going to be processing the upgrade in a series of cycles, run upgrade to get error messages, roll back db&data and fix the data error, wash rinse repeat until clean. I usually start an SQL script to add all of the SQL changes so when I restore, I can apply previous identified fixes and then add the new fix. When you're done, you'll have a SQL script to run against your prod DB and complete an upgrade. Oh, and you don't just do an upgrade in production, you do this in a clone of prod to work through all of the upgrade issues before attempting the prod upgrade.

That said, you now have to dig into your DB. Investigate the definition of PORTALMGR.SYS_C00108915 to see what data has to be unique. That will point you at the table that has non-unique data. Review the data and perform necessary cleanup in your restored environ and try again.

[7年前 に Meenakshi Kandasamy によって更新されました。]

Thanks for the reply David.

This index is created for the layoutFriendlyURL table for the column layoutFriendlyURLID. In the layoutfriendlyURL table , i couldn't find any duplicate.

Also , in the upgrade docuement , it is saying the following(bolded below) : WHich table i have to check for this URL value as '/global'? is it any way that i can print the sql statement to see the value that it is trying to insert in the table?

Note: In Liferay 6.2, the Global repository that was used to store Web Content and Documents and Media is now its own site with the reserved friendly URL /global; upgrading to Liferay 6.2 will fail if any sites are using the same URL. Before upgrading to Liferay 6.2, make sure no current friendly URL violates the restriction.

Thanks

[7年前 に David H Nebinger によって更新されました。]

That would be the group table...

[7年前 に Meenakshi Kandasamy によって更新されました。]

I cleaned up the database in test and start the upgrade yesterday afternoon at 3:00 PM and it is still running. No errors yet but the upgrade is taking lots of time on the following step. we are using oracle 11g database but the log is saying "Verifying com.liferay.portal.verify.VerifySQLServer". I am not sure why the verifyPermission is taking this much time. Can somebody help me to point out where i can check what it is doing and why it is taking this much time?

19:05:50,236 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifySQLServer
19:05:50,238 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyUUID
19:22:57,019 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyPermission

Thanks

[7年前 に Meenakshi Kandasamy によって更新されました。]

Anybody had this problem of taking too much time on verifyPermission update process?

[7年前 に David H Nebinger によって更新されました。]

It can take a long time depending upon the size of your data and the number of users you have. If you have a large dataset this will take some time to complete.

If you check your database you should see queries being executed against your database as part of the ongoing verification.

[7年前 に Meenakshi Kandasamy によって更新されました。]

is it anyway that we could faster the upgrade by running the verifypermission process separately?

[7年前 に David H Nebinger によって更新されました。]

No. If there was, it would have been shared by now.

The data is what it is, and the upgrade takes what it takes.

Sometimes you can analyze the queries and identify some indexing that you can add to help out, but it will still take awhile to run.

[7年前 に Meenakshi Kandasamy によって更新されました。]

Upgrade finished with the following error. Any thoughts?

Caused by: org.springframework.transaction.TransactionSystemException: Could not roll back Hibernate transaction; nested exception is org.hibernate.TransactionException: JDBC rollback failed
at org.springframework.orm.hibernate3.HibernateTransactionManager.doRollback(HibernateTransactionManager.java:679)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:845)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:822)
at com.liferay.portal.spring.transaction.DefaultTransactionExecutor.processThrowable(DefaultTransactionExecutor.java:134)
at com.liferay.portal.spring.transaction.DefaultTransactionExecutor.execute(DefaultTransactionExecutor.java:65)
at com.liferay.portal.spring.transaction.TransactionInterceptor.invoke(TransactionInterceptor.java:51)
at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:111)
at com.liferay.portal.spring.aop.ServiceBeanAopProxy.invoke(ServiceBeanAopProxy.java:175)
at com.sun.proxy.$Proxy153.checkEntries(Unknown Source)
at com.liferay.portlet.blogs.service.BlogsEntryLocalServiceUtil.checkEntries(BlogsEntryLocalServiceUtil.java:389)
at com.liferay.portlet.blogs.messaging.CheckEntryMessageListener.doReceive(CheckEntryMessageListener.java:28)
at com.liferay.portal.kernel.messaging.BaseMessageListener.receive(BaseMessageListener.java:26)
... 11 more
Caused by: org.hibernate.TransactionException: JDBC rollback failed
at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:200)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doRollback(HibernateTransactionManager.java:676)
... 22 more
Caused by: java.sql.SQLException: Protocol violation
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:459)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:191)
at oracle.jdbc.driver.T4C7Ocommoncall.doOROLLBACK(T4C7Ocommoncall.java:68)
at oracle.jdbc.driver.T4CConnection.doRollback(T4CConnection.java:649)
at oracle.jdbc.driver.PhysicalConnection.rollback(PhysicalConnection.java:3893)
at org.apache.tomcat.dbcp.dbcp.DelegatingConnection.rollback(DelegatingConnection.java:368)
at org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.rollback(PoolingDataSource.java:323)
at sun.reflect.GeneratedMethodAccessor1252.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy$LazyConnectionInvocationHandler.invoke(LazyConnectionDataSourceProxy.java:376)
at com.sun.proxy.$Proxy3.rollback(Unknown Source)
at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:213)
at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:192)
... 23 more
08:21:42,939 INFO [liferay/scheduler_dispatch-6][PluginPackageUtil:1280] Reloading repositories

[6年前 に Prashant Sharma によって更新されました。]

Hi,

Working with Migration from Liferay 6.1 to Liferay 6.2 ce ga6 is creating an issue while DB migration using Linux OS.
I have Restored LR6.1 db in db (say lportal_62) and configured it with liferay-portal 6.2 ce ga6. While starting the server with restored DB logs get freezed on below mentioned line.

/Tomcat7.0/logs/catalina.out:

09:41:07,265 INFO [localhost-startStop-1][BaseDB:98] create index IX_76F15D13 on Website (uuid_);
09:41:07,266 INFO [localhost-startStop-1][BaseDB:98] create index IX_712BCD35 on Website (uuid_, companyId);
09:41:07,268 INFO [localhost-startStop-1][BaseDB:98] create index IX_B54332D6 on WikiNode (companyId, status);
09:41:07,269 INFO [localhost-startStop-1][BaseDB:98] create index IX_23325358 on WikiNode (groupId, status);
09:41:07,270 INFO [localhost-startStop-1][BaseDB:98] create index IX_E0E6D12C on WikiNode (uuid_, companyId);
09:41:07,272 INFO [localhost-startStop-1][BaseDB:98] create index IX_64CCB282 on WikiPage (nodeId, head, redirectTitle);
09:41:07,275 INFO [localhost-startStop-1][BaseDB:98] create index IX_40F94F68 on WikiPage (nodeId, head, redirectTitle, status);
09:41:07,277 INFO [localhost-startStop-1][BaseDB:98] create index IX_85E7CC76 on WikiPage (resourcePrimKey);
09:41:07,278 INFO [localhost-startStop-1][BaseDB:98] create index IX_E1F55FB on WikiPage (resourcePrimKey, nodeId, head);
09:41:07,280 INFO [localhost-startStop-1][BaseDB:98] create index IX_1725355C on WikiPage (resourcePrimKey, status);
09:41:07,281 INFO [localhost-startStop-1][BaseDB:98] create index IX_5DC4BD39 on WikiPage (uuid_, companyId);
09:41:07,345 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyProcessSuite
09:41:07,346 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyProperties
09:41:07,362 ERROR [localhost-startStop-1][VerifyProperties:206] Portal property "velocity.engine.resource.manager.cache.enabled" is obsolete
09:41:07,392 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyDB2
09:41:07,392 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyMySQL
09:41:07,393 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyOracle
09:41:07,393 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifySQLServer
09:41:07,394 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyUUID
09:41:07,899 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyPermission
09:41:09,136 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyGroup
09:41:09,479 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyRole
09:41:10,370 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyAsset
09:41:10,403 INFO [localhost-startStop-1][UpgradeProcess:164] Upgrading com.liferay.portal.upgrade.util.UpgradeAssetPublisherManualEntries
09:41:10,405 INFO [localhost-startStop-1][VerifyProcess:65] Verifying com.liferay.portal.verify.VerifyAuditedModel

I wait for sometime, still the logs doesn't changed.So i stopped the server.
On restarting liferay-portal with same DB, it starts and shutdown with an exception as mentioned below :

/Tomcat7.0/logs/catalina.out:

07:37:01,462 WARN [localhost-startStop-1][UpgradePortletId:332] org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique con straint "ix_edb9986e"_ Detail: Key (name, actionid)=(1_WAR_calendarportlet, ACCESS_IN_CONTROL_PANEL) already exists.
org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "ix_edb9986e"_ Detail: Key (name, actionid)=(1_WAR_calen darportlet, ACCESS_IN_CONTROL_PANEL) already exists.
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2103)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1836)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:512)

07:37:01,592 INFO [localhost-startStop-1][Table:157] Starting backup of DLFileEntryType to /opt/portalce/liferay-portal-6.2-ce-ga6/tomcat-7.0.62/ temp/temp-db-DLFileEntryType-1521617821592
07:37:01,598 INFO [localhost-startStop-1][Table:191] Finished backup of DLFileEntryType to /opt/portalce/liferay-portal-6.2-ce-ga6/tomcat-7.0.62/ temp/temp-db-DLFileEntryType-1521617821592 in 6 ms
07:37:01,713 ERROR [localhost-startStop-1][MainServlet:234] com.liferay.portal.kernel.events.ActionException: com.liferay.portal.kernel.upgrade.Up gradeException: com.liferay.portal.kernel.upgrade.UpgradeException: org.postgresql.util.PSQLException: ERROR: value too long for type character va rying(75)
com.liferay.portal.kernel.events.ActionException: com.liferay.portal.kernel.upgrade.UpgradeException: com.liferay.portal.kernel.upgrade.UpgradeExc eption: org.postgresql.util.PSQLException: ERROR: value too long for type character varying(75)
at com.liferay.portal.events.StartupAction.run(StartupAction.java:80)
at com.liferay.portal.servlet.MainServlet.processStartupEvents(MainServlet.java:1246)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:231)


Please let me know if anyone is aware with any of these exception.

Regards
Prashant Sharma

[6年前 に David H Nebinger によって更新されました。]

Prashant Sharma:

I wait for sometime, still the logs doesn't changed.So i stopped the server.

That's a mistake. Depending upon the row count in the database, upgrades can take a long time. I've seen cases where a big database being updated by an underpowered computer can take days to complete.

Normally things are not logged while the upgrade is running, you just have to wait it out. It will eventually either succeed and move on or fail and report the error, but it is running.

The errors you got after failing to complete the upgrade, those are unfixable errors resulting from some data being updated but not all. It cannot be repaired or restarted, you have to rollback the database and start over again.

[6年前 に Prashant Sharma によって更新されました。]

Hi David,

Thanks a lot for your response, it seems I need to wait for a night and keep the server up.
Is there any specific time as per the Database size??

Regards
Prashant Sharma

[6年前 に David H Nebinger によって更新されました。]

No, it always depends upon what kind of content you have and how much there is. Each site is different so there is often little value comparing upgrade times.

[6年前 に Prashant Sharma によって更新されました。]

Hi David,

Finally the issue has been resolved. Issue was related to portal-ext .properties file.
I was getting "bad pool size" error while serve was getting started as mentioned below :

03:18:25,657 INFO [localhost-startStop-1][DialectDetector:136] Found dialect org.hibernate.dialect.PostgreSQLDialect
03:18:27,057 WARN [localhost-startStop-1][BasicResourcePool:275] Bad pool size config, start 10 > max 5. Using 5 as start.

Solution : As a change i have increased the pool max and min size from properties file.

jdbc.default.maxPoolSize=15
jdbc.default.minPoolSize=10

Thanks David for you support

Regards
Prashant Sharma