Recovery steps after ALM corruption

ALM is HP's software development lifecycle software, its full name is Application Lifecycle Management, its use of B/s structure, from requirements, business models to test cases and defect management should also have, to meet the General software enterprise development of products and projects throughout the management , the function is powerful and easy to use.

My company's use of ALM using Microsoft SQL Server as its database, has been used well, but in Saturday, the office in Friday without notice in the case of temporary power outages for several hours, although there are ups, but the power outage is too long, resulting in ALM and SQL Server (both deployed in the same machine) is still on the machine or shutdown because of a power outage. When this Monday morning to work to find the shutdown, start the machine still found unusable, then found that the corresponding database in suspect state.

After looking for data, it is very easy to do a good job of the database (the specific process to see the MS SQL Server 2008 database in the case of suspect processing), but ALM is still unavailable, the main performance is to create defect prompts after login error, the execution test case also prompts the same error, as shown in the following

Looking for information again, but didn't find the relevant information, and finally had to switch machines to reinstall SQL Server and ALM, this time I put SQL Server and ALM installed in separate machines.

After that, in the original ALM with the administrator account into the site management, the previous project was exported successfully, the exported file name extension is. qcp.

Finally, when you create a new project in new ALM and take a project that was exported before you imported it, I found that I would import the previous database as well, which means I don't have to deal with database data.

When the import was complete, the cup was found: unable to sign in.

Due to the lack of information to find, we have to try to solve the problem themselves: the import of the project to verify, as shown in the following figure. The result of the verification is that a problem has been found, and then the item was repaired and the fix was successful, but still unable to log on.

Then tell yourself to be calm, and carefully check your own process: found that the original ALM is a SP2 version, The newly installed ALM is version 11.0, and then the new installation of ALM SP2, after the installation of the completion of the login and execute test case test, found that there is no problem, it is really gratifying ah.

Summary of lessons Learned:

1. The ALM database needs to be backed up so that it can be restored at the time of the problem, with a single, incremental backup every day. If you back up before, it will not be so troublesome. In addition to spit out Microsoft's SQL Server database, really too fragile, power outages such a common thing that caused the database to hang up, and at that time no one to the ALM and SQL Server operation, the database actually prompts the log file incomplete.

2.ALM itself is more cumbersome to backup, if there is a problem, you can use the pilot out of the project, and then reinstall ALM and import the project, but remember to keep the same as the previous ALM version OH.