Migrate JIRA H2 to MsSQL - failing for queues and reports

Question

Hi

We have a test install of JIRA / Service Desk which is using the internal H2 database . We now wish to transfer the data to our SQL server install and have followed the steps for migrating to a different database.

We have tried on the same server, as well on a test environment and whilst it all appears to work OK, we are missing data in each test we have done.

The H2 database is quite large (+8Gb) and the backup file that gets geneated is 1.3Gb.

Most of our JIRA issues etc are showing OK, but our Service Desk custom queues are always missing.  Also missing are all our custom reports.

Is there any other method to export data from the H2 database?  Especially given that the SQL Server is running with the necessary tables.

In terms of data, the table AO_54307E_QUEUE on SQL shows the 4 queues:

Due soon
SLA breached
SLA at risk
My open tickets

however the H2 database has 60 rows of data.

Nic Brough -Adaptavist- · Answer

I wasn't intending to come across as sarcastic, just light-hearted.

An export/import will carry over all your data, so I can't tell what's going wrong.  You've said "it doesn't work", but that doesn't tell us what is wrong.  Is it just the queues and reports?  I can't work out a way to loase those when you're doing a plain export/import.

Craig Hoskin · Answer

Thanks for the reply, but dont shot the messenger.  It wasnt my call to use the Internal DB, Im merely being asked to step in at tooo later stage!

As above, I thought I had posted some information.  If there wold be something specific , then just lt me know ,... but please drop the sarcasm!

From all I can see it "has worked", except when the staff go to use it they say, as I have noted above, that the Custom Queues and Custom reports dont exist.  Everything else, by all observation, is OK.

Thanks for your help,  but maybe we will have to backout and look at another product.

Nic Brough -Adaptavist- · Answer

An 8Gb "test" system stopped being "test" around 7.9Gb ago.  You should have moved to a proper database as all the documentation said at the time.

Exporting it to XML so you can import it into a real database  really is the best option, and possibly the only one.

So, going to look at the actual problem.  "... so when that doesnt work ..." tells us nothing about it.  For all we know, it has not worked because a penguin wandered into your office and bit the network cable part way through, or something equally silly.  Please explain the actual problem with the migration, then we might be able to help.