After migrating the Bitbucket Server database from one Oracle server to another, the application leads to an error during start up: missing table [bb_alert]
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Problem
After migrating a Bitbucket database from one Oracle server to another the application doesn't start up with following error in atlassian-bitbucket.log:
1
2
ERROR [spring-startup] c.a.j.s.w.s.JohnsonDispatcherServlet SpringMVC dispatcher [springMvc] could not be started
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'crowdAliasDao': Unsatisfied dependency expressed through method 'setSessionFactory' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [stash-context.xml]: Cannot resolve reference to bean 'sessionFactoryPrototype' while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactoryPrototype' defined in class path resource [stash-context.xml]: Invocation of init method failed; nested exception is org.hibernate.tool.schema.spi.SchemaManagementException: Schema-validation: missing table [bb_alert]Cause
According to the article Connecting Bitbucket Server to Oracle, whenever a DB is created in Oracle, a local all_objects view to the user's schema must be created in the ownership of the DB user.
If the new schema is set up with a different user as the owner rather than the one in the original, then the all_objects view (which is also copied along with the tables) would not allow the application to read the tables due to insufficient privileges.
Resolution
Reassign ownership of the all-objects view to the new user in the migrated schema and restart the application.
Was this helpful?