When I am trying to restore a JIRA backup, the following exception is thrown.
"java.lang.RuntimeException: org.apache.jasper.JasperException: com.atlassian.activeobjects.internal.ActiveObjectsSqlException: There was a SQL exception thrown by Database.
com.mysql.jdbc.exception.jdbc4.MySQLSyntaxErrorException: Table 'target.ao_60db71_rapidview' doesn't exist." Suggestion as per this link also didn't work [https://confluence.atlassian.com/display/FISHKB/Table+%27xxx%27+doesn%27t+exist+error+with+MySQL+server ] The backup was taken from a Centos machine and am trying to restore in a windows 7 machine. Could it be because of the operating system? Can't I migrate JIRA from one OS to a different OS.
It's nothing to do with the operating system - there's something wrong in the import. Not sure why you are trying to read Fisheye documentation for a JIRA issue though.
The usual culprit is the versions of the software. Is your target JIRA exactly the same version as the source JIRA? And has the same version of the Agile plugin installed?
If they are, then check the other known culprits in https://confluence.atlassian.com/display/JIRAKB/JIRA+Entity+Mismatch+with+Database+Schema
The error "com.mysql.jdbc.exception.jdbc4.MySQLSyntaxErrorException: Table 'target.ao_60db71_rapidview' doesn't exist." indicates that JIRA wasn't able to find the table 'target.ao_60db71_rapidview', which is needed to store JIRA Agile information.
As explained by Nic, it is very unlikely that this is related to the OS. I would recommend you to review your DB configuration as per the Connecting JIRA to MySQL document, and try to perform the import again.
You may also look into the recommended method for migrating JIRA to another server in the document below:
If you encounter any issues even following the documents above, please report a support ticket, providing us with your JIRA logs and also with the detailed steps you have performed to restore the backup.
"JIRA wasn't able to find the table 'target.ao_60db71_rapidview', which is needed to store JIRA Agile information.". True, Rapidview table didn't exists at that time. Wondered how it got deleted. - I installed JIRA. - Installed all the plugins. - Shutdown JIRA. - Checked the tables in MySQL DB. All the plugins tables starting with 'ao_' exists. I also saw the presence of 'ao_60db71_rapidview' table in MySQL DB. - Started JIRA instance and proceeded with restoration. ActiveObjectsSqlException thrown and restoration failed. Checked the tables in MySQL DB. All the tables beginning with 'ao_' names doesn't exist now. One month back I did the same exercise of restoring the backup from the same source JIRA. It went smoothly without any issues. Now this is posing a issue. I have been playing around JIRA for the past 3 years and never faced any issue like this. Anyway, this is new and my learning zone is expanding.
While it isn't something I've seen before, this could have to do with Active Objects's use of uppercase table names interacting badly with MySQL's way of dealing with database tables. MySQL uses a file on disk with the same name as the table, and whether or not it is case-sensitive about the table name depends on whether or not the file system is. Active Objects tries to force its table names to uppercase, but since The NTFS file system on Windows is not case sensitive, this might not work as expected. I'm making this guess based on the fact that it is reporting problems with the table 'target.ao_60db71_rapidview' when I would expect it to Be working with it as 'target.AO_60DB71_RAPIDVIEW'.
As Danilo says, a support ticket is probably the best way to sort this out.
I suspected the same initially and MySQL system variable lower_case_table_names value differ from Windows OS to Cent OS. In windows, the default is 1 and in CentOS the default is 0. So I changed the system variable to 0 as the backup was taken from CentOS box and restarted the MySQL server but still the same Exception. Then I realised that I did the same exercise of restoring the backup(1 month old) last month taken from the same source JIRA and it went through smoothly without issues. This exercise was done on the same MySQL which had the system variable of lower_case_table_names as 1. My question and puzzle is, what went wrong now to throw this exception?
As others have mentioned, this would be best dealt with in a support ticket, but let's see if we can find why this has been happening. Could you confirm that your database configuration is the same mentioned in this page: https://confluence.atlassian.com/display/JIRA/Connecting+JIRA+to+a+Database
If it's not, would you mind creating a new database following this page and let us know if the issue repeats itself?
Thank you all for the reply. I tried restoration on a fresh exe based JIRA installation and it worked fine. Probably there are some issues when I did the restoration in zip based JIRA installation. Some previous cache may not be cleared. I didn't do further investigation as JIRA executable is working fine.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs