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. 🙂