We are a dev company that develops and supports an application based on DB2 LUW 10.5 for a customer. We have a VPN that gives us access to our customer's production environment, and we often connect to the production DB2 server directly to investigate various issues. We want to avoid accessing the production database in this way, so we'd like to create a copy of the production database on our network.
The production server is currently replicated to a DR site using HADR. HADR with the read only option would give us what we wanted but we want to avoid the need to purchase another license for our server – we'd like to just use the Express-C edition of DB2. Log shipping may be possible but from what I read the database is not accessible while in the state to accept logs.
For the solution to work the target database would need to be fairly up to date. It can be read-only but that is not a requirement. If it is not read-only we would not want to push changes back to the master.
What options are available for this scenario? Thanks in advance for any ideas.
Best Answer
If you wish to use Express-C, your best options are probably either mirroring the disk and logs using an OS utility (I believe best done on Unix) or through taking backups and copying them to the standby server and then restoring them.
HADR won't work with Express-C. And I'm not sure that pureScale will either (although I can't say with 100% certainty.)
Do note that not every feature from higher editions of DB2 (such as Enterprise) won't work on Express-C. Multidimensional Clustering Tables (MDCs) or BLU for example. So if your client uses those features someone is going to have to pay for a license for another server.
I guess I would also question what data may be in that production server that a client wishes to allow you to have? Or that you wish to have? That is pretty dangerous. Developers should have limited access to production data. It should be specific and timed. Otherwise a copy with scrambled data should be restored to a test or dev environment (still preferably on their equipment). A good DBA shouldn't just let someone have access to production unless they have signed in blood so to speak. I'd go so far as to say a DBA shouldn't really even be able to see the data in production. I digress.