Hi Varun,
some additional thoughts:
The document Britta referenced is meant to move the DB to a different SQL Server, but still being connected to the same SOI environment.
You can use the same procedure to restore the DB into a different environment (from Production to UAT), but you will not be able to "test" anything in that environment, because all identifiers refer to the original environment.
In UAT all connectors will have different identifiers, and thus you will get all the CIs from these connectors in addition to the ones you restore from Production.
If you only want to test that moving a DB works, e.g. see if all info is still available following the move, the procedure is fine. But you cannot continue using the DB in the UAT environment, because the info in the DB will be a mix of both environments with all info coming from Production pointing to non-existing CIs.
CA Support is often using the procedure to get a customer's DB into a local environment, but only to analyze tables or find inconsistencies, e.g. a static snapshot.
MichaelBoehm