[JIRA] Lexorank integrity issues?

So, this is loosely another part of the unofficial series ‘fixing a corrupted JIRA db‘.

However, this is a different case. This JIRA instance (7.1.x) was created by importing a huge XML backup (> 1 million issues). Due to an unknown reason, ActiveObjects didn’t import. That means, JIRA Software (aka JIRA Agile) no longer functioned normal.

It was soon discovered that Lexorank integrity checks fail. For the record, following integrity checks failed:

Marker rows present in table for rank field
Marker rows correctness check
Marker rows in valid bucket check
Issue rows in valid bucket check
Balance status check

Now what? I made an unsuccessful attempt of uninstalling JIRA Software, then dropping all database tables/ triggers/ sequences with the prefix AO_60DB71_ and then re-installing JIRA Software. This didn’t help.

Then, I wanted to study the under-the-hood stuff of Lexorank management. I already knew of two database tables involved, AO_60DB71_LEXORANK and AO_60DB71_LEXORANKBALANCER.

First I created a custom field of type ‘Global Rank’ and named it ‘Rank2’.

Then, I navigated to JIRA Administration –> System –> Lexorank management. Now I could see two Rank fields under the Balancing section. I balanced them once again and executed the integrity checks. The old one still failed the above checks, but the new one passed all checks!

Now, let’s take a look at the database. Following query returned two rows, that looked like an upper marker (1|zzzzzz:) and a lower marker (1|000000:). Both were associated with the field ID of the newly created ‘Rank2’ custom field.

select * from AO_60DB71_LEXORANK;

What I did was a very simple thing. I updated the field ID of the two records so they are now associated to the old Rank field.

update AO_60DB71_LEXORANK
set FIELD_ID = (select ID from CUSTOMFIELD where CFNAME = 'Rank');

commit;

Finally, to clean up I deleted the newly created Rank2 custom field. Simple!

After a JIRA restart Lexorank started to function normal, with all the integrity checks passed. I hope my approach will help someone who has run into the same problem.

[JIRA] Broken Permission Schemes? (better way)

Yesterday I blogged about how to fix JIRA Permission Schemes of a corrupted JIRA database. The observation was from atlassian-jira.log, but in my case I soon found out the problem was much greater in my case.

All projects lost their workflow scheme, issue type screen scheme, and field configuration scheme, and project category associations. This led me to peek into the database directly. The NODEASSOCIATION table had only 20 – 30 rows – those are the permission schemes I fixed yesterday. Also, all issues lost their components, affected versions and fix versions.

So how do I fix this? I can fix issue type screen scheme association without a hassle, notification schemes without a hassle, but workflow schemes? Even automating the restoration may run into dead ends given the nature of steps of workflow scheme association through UI. The only option seemed to be restore the corresponding records to NODEASSOCIATION table from the most recent database backup.

This is actually safer than meddling with other database tables in JIRA, because NODEASSOCIATION has no primary key, so no chance of primary key violation errors after starting up JIRA. With all sounded good, here’s my steps.

  1. From the most recent backup of the same JIRA instance, export the NODEASSOCIATION table. With Oracle SQL Developer there’s an option to export records in ‘INSERT’ format, which generates a SQL script.
    • If you use another database/ client that can’t export into ‘INSERT’ format, you can export to a CSV or spreadsheet and then use spreadsheet formulae to generate INSERT queries.
    • In my case I had to exclude where SINK_NODE_ENTITY = ‘PermissionScheme’ because I’ve already fixed that.
  2. In the target JIRA database, run the above SQL script and commit. Easy! 😀
  3. Restart JIRA and re-index.

This added some 60,000+ records with all entity association you’ll find out with this query:

select distinct source_node_entity, sink_node_entity, association_type from nodeassociation order by 1 asc;

That’s it! Not 100%, but this worked up to my expectation. The key reason for this being hassle-free and easy is, NODEASSOCIATION table has no primary key. This is actually much much better than using Groovy, because you have to pay for the add-on. 🙂

[JIRA] Finding issues that contain LucidChart diagrams

One of the coolest JIRA add-ons you could find in the market is LucidChart. LucidChart is an easy-to-use diagramming software. However, once you start using it in your JIRA, it stores diagrams in it’s own way.

Have you ever come across a requirement to find all issues in your JIRA instance that contains LucidChart diagrams? Well, I’m on JIRA 6.x and currently there’s no JQL function that I know to help with this. At least we have SQL – so JIRA administrator can look up if that’s really important.

So, here’s the fish. All you have to do is to set up a database client to access your JIRA’s database and fire up this query.

select distinct p.pkey || '-' || i.issuenum
from propertyentry pe
inner join fileattachment fa
  on pe.entity_id = fa.id
inner join jiraissue i
  on fa.issueid = i.id
inner join project p
  on i.project = p.id
where
  pe.property_key = 'lucidchart.attachment.id';

Simple as that! Then, here’s how to fish.

There was no official documentation telling you how to do this. So how do we find the relation and database tables that contain LucidChart diagram data? Following the guesses is the answer.

Continue reading

Oracle:: Drop all tables in a single shot

If you are into software development, you may have wanted to drop all tables of an Oracle database schema in a single shot. How do you do it? Here’s how I do it with a simple PL/SQL procedure.

begin
for i in (select * from tabs) loop
execute immediate ('drop table ' || i.table_name || ' cascade constraints');
end loop;
end;
/

‘tabs’ is actually an in-built view in Oracle. As explained in the follwing forum post, this PL/SQL block affects only the logged in user’s (schema) tables only.
https://community.oracle.com/message/10359255#10359255

Oracle :: How to query all table columns except views

As per the documentation provided in the following page, once you query ALL_TAB_COLUMNS, database views and view columns are also included. There’s nowhere specified whether the table is actually a table or a view.

http://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_2094.htm

However, with the following SQL it’s easy to exclude views and retrieve table columns only.

select 
  table_name,
  column_name,
  data_type,
  data_length,
  column_id
from
  all_tab_columns
where
  owner = 'SCHEMA_NAME' and
  table_name not in (select view_name from all_views where owner = 'SCHEMA_NAME')
order by 1, 2, 3;

It saved my day! 🙂