Dear Experts,
I have been recently hired as an IT person for this company. Although my job description did not include this, I am thinking of bringing in the database that was developed by the outside consultant group in-house for better control of the application, and also for compliance.
My questions is, how difficult is it for me to master a database written in Perl, Mason, and PostgreSQL? I have a background in C++, Java, VBA programming, am familiar with Unix system, am pretty good with SQL, HTML, and have created and managed database system using MS ACCESS with VBA codes. The only experience I do not have is creating web-based application.
I am wondering, should I hire someone as a DBA, who already knows Perl and PostfreSQL, and I become a backup programmer for that person, or can I manage myself? (The reason I am wondering is I am not sure I can justify the salary of DBA at this point.)
Because this web portals for the database is the heart of my company's operation, I would not rush to get anything done, and obviously need cooperation from the consultants that are currently writing these apps.
Please advise.
I've had plenty of experience with exactly these kinds of scenarios. When I worked in hosting, it was an almost-everyday occurrence that a customer needed a database moved either to, from, or within my company. It is always more painful when you do not have the full support of the hosting company, but their cooperation is only necessary to the extent that you need full access to the database. That access can come as shell access into the server or maybe just access to a point-in-time backup that you can trigger.
The process I've always followed:
1) set up a working sandbox copy of the application. It should point to a working copy of the existing database, preferably on the existing server. You want your starting environment to be as close as possible to your production environment.
2) Attempt to copy the database to your new platform, also a sandbox. This means getting a point-in-time backup of the current database, restoring it into the new environment, and verifying its responsiveness.
3) Change your sandbox application to hit the database copy.
If you can successfully complete those three steps, then you know you can safely migrate with very little interruption. Document the process thoroughly, and test it even more so. If done properly, the only downtime you'll need to experience is the final backup/restore.