---
title: "Testing"
canonical: "https://kb.myframeworks.com.au/space/PROSTIXV48DOC/31100690/Testing"
format: markdown
---
It's no use having these DR processes running in the background if they are not checked and tested periodically. Sterland suggest that initially you plan for running a test process weekly for the first few weeks, just to iron out any issues, to modify the documents and procedures involved, and to become comfortable with the process. The last thing you want in a disaster situation is to be floundering in a panic. There are 2 methods of testing required: 1. Testing DR Demo 2. Testing DR Live Testing DR Demo This testing allows you to non-destructively log into the working copy DR Demo database to check that the actual data is correct and up-to-date, and that you can process new transactions, print them and so on. It is non-destructive in the sense that the DR Demo DB is refreshed typically each night on the DR server from the DR Live DB, and the testing does not touch the DR Live DB. To test the DR Demo, perform the following: 1. Log into the DR Server 2. From Promenu, select option 18, Start Database Server 3. Then select option 3, to start the DR Demo DB 4. From Promenu, select option 2, to log into Prostix DR Demo 5. Check the data is current and up to date, that is, yesterday's 6. Process test transactions, checking data, functionality, access & printing all work as expected 7. When finished, be sure to log out of all ProStix sessions. There is no need to stop the DR Demo DB, as the drlive2demo.sh script does this, so long as there are no active ProStix DR Demo sessions. Testing DR Live Although the previous test, Testing DR Demo, allows you to be fairly confident that the DR process is working correctly, it doesn't allow you to actually test logging into the DR Live Database. For example, testing the script to start the DR Live DB, testing for permissions and login access to it, and so on. However, the problem with this second form of testing, is that once you access the DR Live DB, you disable its ability to have any further AI files applied to it from the Production server. Nevertheless, it is unavoidable, as there really is no other way to ensure that the environment correctly allows you to switch if the need arises. Once you have accessed the DR Live DB, you need to refresh it. To test the DR Live DB is almost identical to Testing DR Demo above, with a few extra steps: 1. Disable the AI Engine. It no longer functions and produces email alert failures. 2. Log into the DR Server 3. From Promenu, select option 18, Start Database Server 4. Then select option 1, to start the DR Live DB 5. Note the Warning message that this renders the DB out of sync 6. From Promenu, select option 1, to log into ProStix DR Live 7. Check the data is current and up to date, that is, within [SyncInterval] 8. Process test transactions, checking data, functionality, access and printing all work as expected 9. When finished testing, you need to refresh the DR Live DB, such as:   Check Printers Some sites have their printers synchronised between the Production & DR servers, some do this manually. In either case, be sure that your regular testing includes checking that all the print queues that you need operational on the DR server do exist and work as expected.Some sites have a scaled down DR server configuration to support only skeleton staff, so it may not be necessary in all cases that every print queue on the Production server exists on the DR server.