Unable to access repo after upgrading Bitbucket 9+ with Oracle database

関連コンテンツ

  • 関連コンテンツがありません

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

プラットフォームについて: Data Center - この記事は、Data Center プラットフォームのアトラシアン製品に適用されます。

このナレッジベース記事は製品の Data Center バージョン用に作成されています。Data Center 固有ではない機能の Data Center ナレッジベースは、製品のサーバー バージョンでも動作する可能性はありますが、テストは行われていません。サーバー*製品のサポートは 2024 年 2 月 15 日に終了しました。サーバー製品を利用している場合は、アトラシアンのサーバー製品のサポート終了のお知らせページにて移行オプションをご確認ください。

*Fisheye および Crucible は除く

要約

After upgrading Bitbucket, repository access fails even though the application starts with success.

After upgrading from version 8, or older, to 9+, users encounter repository access issues, with HTTP 500 being thrown in the UI due to Oracle database constraints.

環境

  • Bitbucket Version: 9+ (upgraded from 8 or older)
  • Database: Oracle DB (with ActiveObjects tables)

ソリューション

Verify indexes on the problematic table

 Note that these queries need to be executed with the Bitbucket database account owner.

Step 1: Shutdown Bitbucket to ensure it is not interacting with the database during testing.

Step 2: Run the ALL_INDEXES query and keep a record of the results (label result as step 2).

SELECT NULL     AS table_cat,
       owner    AS table_schem,
       table_name,
       0        AS NON_UNIQUE,
       NULL     AS index_qualifier,
       NULL     AS index_name,
       0        AS type,
       0        AS ordinal_position,
       NULL     AS column_name,
       NULL     AS asc_or_desc,
       num_rows AS cardinality,
       blocks   AS pages,
       NULL     AS filter_condition
FROM   all_tables
WHERE  table_name = 'AO_8E6075_MIRROR_SERVER'
       AND owner = '<BITBUCKET_DB_OWNER_ACCOUNT>'
UNION
SELECT NULL              AS table_cat,
       i.owner           AS table_schem,
       i.table_name,
       Decode (i.uniqueness, 'UNIQUE', 0,
                             1),
       NULL              AS index_qualifier,
       i.index_name,
       1                 AS type,
       c.column_position AS ordinal_position,
       c.column_name,
       NULL              AS asc_or_desc,
       i.distinct_keys   AS cardinality,
       i.leaf_blocks     AS pages,
       NULL              AS filter_condition
FROM   all_indexes i,
       all_ind_columns c
WHERE  i.table_name = 'AO_8E6075_MIRROR_SERVER'
       AND i.owner = '<BITBUCKET_DB_OWNER_ACCOUNT>'
       AND i.index_name = c.index_name
       AND i.table_owner = c.table_owner
       AND i.table_name = c.table_name
       AND i.owner = c.index_owner
ORDER  BY non_unique,
          type,
          index_name,
          ordinal_position;

Step 3: Manually add the constraint back in

ALTER TABLE "ao_8e6075_mirror_server"
  ADD CONSTRAINT u_ao_8e6075_mirror_881127116 UNIQUE ("add_on_key");

Step 4: Run the query from step 2 and keep a record of the results (label result as step 4)

Step 5: Manually drop the constraint

ALTER TABLE "ao_8e6075_mirror_server"
  DROP CONSTRAINT u_ao_8e6075_mirror_881127116;

Step 6: Run the query from step 2 and keep a record of the results (label result as step 6)

What to do after the test

The test will eventually produce one of two possible scenarios: The constraint will either disappear from the ALL_INDEXES query result or remain there.

Scenario 1: The constraint is gone from the ALL_INDEXES view

If the result of step 6 shows that the constraint is no longer present in the ALL_INDEXES view, then that means a couple of things.

  • Manually dropping the constraint "fixed" the inconsistent table metadata means Bitbucket can now be restarted without any issues.
  • The fact that a manual drop fixed the issue suggests that there might be a bug in how ActiveObjects performs the drop.

Scenario 2: The constraint is still in the ALL_INDEXES view

On the other hand, if the result from step 6 shows that the constraint is still present in the ALL_INDEXES view, the issue would be with the Oracle DB server not updating this view accordingly. The ALL_INDEXES documentation suggests that you might be able to use DBMS_STATS to update the statistics for the view.

If neither of the two scenarios applies to your situation, you will need to manually drop the index associated with the constraint. This extra step is required because these specific indexes are not of type CONSTRAINT_INDEX , meaning they are not automatically removed when the constraint is dropped.

注意

Note: A CONSTRAINT_INDEX is automatically created by Oracle whenever a primary or unique key constraint is added to a table. These indexes are tied to the constraint and are automatically removed when the constraint is dropped. However, in your case, it seems that the problematic indexes are likely not CONSTRAINT_INDEX, which is why they aren’t being removed when the constraint is dropped.

To address this issue, please follow the steps below:

Step 1: Run the following query to check the type of indexes on the AO_8E6075_MIRROR_SERVER table:

SELECT index_name,
       table_name,
       index_type,
       uniqueness
FROM   all_indexes
WHERE  table_name = 'AO_8E6075_MIRROR_SERVER'
       AND owner = '<BITBUCKET_DB_OWNER_ACCOUNT>';

 This will show all the indexes on the table, allowing you to identify which ones are not CONSTRAINT_INDEX.

Step 2: Once you’ve identified the problematic index, you can remove it manually by using the following command:

DROP INDEX "INDEX_NAME";

 Replace "INDEX_NAME" with the name of the index you want to drop.

Step 2a: If there are multiple non-CONSTRAINT_INDEX indexes on the table, you can use the following script to automatically drop all such indexes:

BEGIN
    FOR idx IN (SELECT index_name
                FROM   all_indexes
                WHERE  table_name = 'AO_8E6075_MIRROR_SERVER'
                       AND owner = '<BITBUCKET_DB_OWNER_ACCOUNT>'
                       AND index_type != 'CONSTRAINT') LOOP
        EXECUTE IMMEDIATE 'DROP INDEX '|| idx.index_name;
    END LOOP;
END;
/

Step 4: Finally, run this query again to confirm that the problematic indexes have been removed:

SELECT index_name,
       table_name,
       index_type,
       uniqueness
FROM   all_indexes
WHERE  table_name = 'AO_8E6075_MIRROR_SERVER'
       AND owner = '<BITBUCKET_DB_OWNER_ACCOUNT>';

診断

  1. Problem Identification: After upgrading Bitbucket, repository access fails even though the application starts with success. 
  2. Log Analysis: Review of Bitbucket application logs revealed inconsistencies in the ActiveObjects (AO) tables and potential issues with Oracle database constraints and indexes.
  3. Key Indicators: The ALL_INDEXES  view in Oracle shows that certain constraints or indexes are not being updated or removed correctly. Dropping constraints does not clear associated indexes due to the nature of non-CONSTRAINT_INDEX entries.  
2025-02-10 08:53:28,411 ERROR [http-nio-7990-exec-10] @1FUS0FIx533x4606x0 62qnp5 10.26.129.244,10.41.76.70 "GET /mvc/error500 HTTP/1.0" c.a.s.i.web.ErrorPageController There was an unhandled exception loading [/projects/TS/repos/hal-product/browse]
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is com.google.template.soy.tofu.SoyTofuException: When evaluating "requirePageData('bitbucket.web.repository.clone.dialog.options', ['repository': $repository])": While computing function "requirePageData('bitbucket.web.repository.clone.dialog.options', ['repository': $repository])": bundle [com.atlassian.bitbucket.server.bitbucket-mirroring-upstream]
	at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1014)
	at com.atlassian.applinks.core.rest.context.ContextFilter.doFilter(ContextFilter.java:28)
	...
java.sql.SQLException: ORA-02443: Cannot drop constraint  - nonexistent constraint

	at com.atlassian.activeobjects.internal.EntityManagedActiveObjects.migrateDestructively(EntityManagedActiveObjects.java:63)
	at com.atlassian.bitbucket.internal.mirroring.upstream.dao.v4.RemoveProductTypeUpgradeTaskV3toV4.upgrade(RemoveProductTypeUpgradeTaskV3toV4.java:22)
	...
	... 35 common frames omitted
Caused by: oracle.jdbc.OracleDatabaseException: ORA-02443: Cannot drop constraint  - nonexistent constraint

	at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:530)
	... 56 common frames omitted

原因

The problem originates from inconsistencies in database constraints and indexes during the upgrade process. More specifically:

  • Oracle Constraint Behavior: Constraints tied to the AO tables are not being properly managed (dropped or updated).
  • Non-CONSTRAINT_INDEX  Issue: The database includes manually created or incorrectly migrated indexes that are not automatically handled by Oracle when constraints are dropped.
Last modified on Mar 27, 2025

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する

関連コンテンツ

  • 関連コンテンツがありません
Powered by Confluence and Scroll Viewport.