What would be potential strategies to getting the old data into a new db structure? One strategy we are thinking of is to write some ruby which executes some sql on a per table basis.
Since this is a one time task(I am preconceiving things here), you might want to have two databases, one old and one created new, from fresh migration. And write a ruby script to copy data as you want from old to new database.
It will help retain the old database and hence the downtime associated with creating new db and reimporting data from dump. You can use your old code until data is migrated and as soon as data migration to new db completes, update the code and restart the server. Voila! whole lot of data migration with no down time! :)
To summarize what I am suggesting:
Keep the old database around, don't recreate and reimport to it
Craete a new databse from fresh migration
create and run the ruby script to copy data from old database to new one
update the application code, which works with new databse
restart the server for new database to kick in
Related
I am new to ssis world, I need to migrate my client's old data to our new database, the problem is schema is completely differ and in some cases i need to save data in two or more different tables and arrange foreign key relationship between them.
Any help is much appriciated
Create a staging database basically a 'bridge', you will make the database as close to the new database as possible, yet still with the old database in mind, you send the old database data to the staging database using SSIS and from there if you wish you can clean the data without interrupting business processes and validate the data to make sure it is balancing to the previous database data count.
From there you move it straight into the new database again with SSIS there should be no issues if the staging database was set up correctly
I'm still fairly new to MySQL, and have an app which uses a MySQL database. What is the proper workflow for copying changes from a development copy to the production DB (indexes, new fields, etc)? So far, I've just used phpMyAdmin to make the changes one at a time, but it seems wrong to work this way.
I have recently migrated one website to a new linux server. But we imported the database of the website was 7days old the actual thing. Now 4 days gone after the migration. So these 4 days database updates which was wriiten to the new server that contains the contents of old server database. We just forget about the 7days database updates from the old server at the time of dns change.
But now our website is having a big issue because they didnt have the missing 7 days database contents. if we imported old database from old server to new server then our latest 4 days database updates on new server will go. Iam in the middle of this.
Can you please suggest a better way to merge these databases into one without any issues or overwritten, so that we can update the same to new server then only the site will run fine. In short we need to merge two databases with the missing contents and site should work fine also. Help me please.
This is going to depend a lot on your data structure (how many auto_increment fields you have, foreign keys, etc.). You will need to dump out everything that was added to the database after the export but prior to the migration, then find a way to import each record.
What is stored in the database?
I've started using the SQLcomplete refactoring tool for SQL Server Management Studio. It appears that every time I add a new database to my instance it doesn't update the SQLcomplete tool with the new schema for that database.
Anybody know how to get around that so it works?
Have you tried pressing Ctrl+Shift+R? This refreshes the cached schema, and can be done any time there is a schema change--which includes adding new databases.
I need to be able to make changes to my development DB,
Such as adding a table or so adding a column.
Is it possible to take this new DB schema and merge it or diff-&-merge it with the production DB without having to rebuild/repopulate the production database?
any tips welcome.
A simple way to do this is to keep track of your ALTER's and CREATE's in a file.
For example, if I were to add a column to a table on the development db, I would copy paste the sql I used into a file called migrate.sql. I would keep doing this until I'm ready to migrate to production.
At this point the file would be a series of sql statements that could be run in order on the production db to "sync" it with the development environment.
If you're not writing the raw queries yourself, you can probably get the commands being run out of whatever GUI tool you're using.