Is there a quick and easy way to backup both SQL Server 2008 and MySQL, all their databases?
Right now I have a batch script that runs, but I have to manually add a database each and every time, and I'm sick of maintaining it. So I want to set it up to backup all SQL Server and then all MySQL, I dont care if its two different solutions, just want the ability to backup all the databases without having to type them in.
Thank you.
2008 - sure. Set up a maintenance bach, tell it to back up all (all user) databases, finished. WIll run regularly and back up the database set asked for. MySQL - no idea.
Related
I am coming from SQL Server where I can find almost anything I need about a database under the systems db's. I am wondering if MYSQL has a system table that will show when the last time a database was backed up via mysqldump.
The whole reason I am asking this is I am trying to create a dashboard/report (SSRS) to show when backups complete or fail. Right now we only get alerted via email so if there is another way I am all ears
I have an old system with sql server database. And I have to create a webiste with mysql database. The old system is still in use and is inserting data to the sql server DB everyday. So, I am thinking write a program that automatically transfer data from the sql server DB to the mysql DB. Any good suggestions? Thanks.
You have an active SQL Server database.
Unless you are planning to decommission this database server (for very good reasons not related to this new application), then the new application should simply query this server.
You can create a small (Maybe in c#) program that keeps running all the times with a timer, and on this timer, get all rows from SQL server that are not marked as "Copied", insert them on MySQL and the update those rows as "Copied". That program need to have access to both databases.
Our company is getting ready to move next week and we currently use SQL Server 2000 for all our databases, hosted in our own building. They've decided to move the data to a local company for several reasons, but they are running SQL Server 2008.
I'd like advice on a few things:
We are trying to setup a test for just a few of our databases to see what breaks with our apps (connection strings, etc.). What is the best way to get a database from our SQL Server 2000 box to the new box without losing data or having to recreate the table, etc. I tried the DB Copy Wizard but restrictions within our network don't allow it. If I create a DB on SQL Server 2008 and perform a RESTORE from the SQL Server 2000 .bak file, I will lose all the transactions, correct? What if I replace the transaction files later? I'm thinking that won't work though.
How to properly upgrade a SQL Server 2000 database to SQL Server 2008? I've run the wizard against most of our databases and it came up clean with the exception of a few minor issues that I can resolve.
Our SQL Server 2000 is our production server so it can't go down at any point to copy files.... not until the move. Our customers have been notified that there will be a short outage period between certain dates so that's ok, but I guess what I'm saying is I can't stop the SQL Server Agent right now just to copy log files and such for testing purposes.
Any help/advice is greatly appreciated!
Create a database backup of the SQL Server 2000 and restore it to the SQL Server 2008.
Setup replication making the SQL Server 2000 as the Publisher and the SQL Server 2008 as the Subscriber.
Not sure which would be the best approach. I think a DB backup and restore would be a good idea. You will loose some data in the mean time, though.
If you were migrating between 2 versions of 2005 or 2008 I would advise a log backup to reduce the data lost but I don't think that this option is available on 2000
One piece of advice I can give you is to take a look at the discontinued features from 2000 and 2005 and from 2005 and 2008 on these links:
2005
2008
Just back up 2000, and then restore it. You won't lose transactions, no difefrent to doing a full backup on your current server.
You'll need to add any SQl logins and set the permissions etc.
You'll need to to do fix users for them as well.
If you only use integrated access then you don't need to.
e.g.
Use MyDataBase
EXEC sp_change_users_login Auto_Fix, 'MyUser'
And you'll need to set the compatibility level
Use
exec sp_bcp_dbcmptlevel 'model'
to get it
and then
EXEC sp_dbcmptlevel 'MyDatabase', ??
to set it.
Another option, would be to install 2000 on your new machine restore a back from the old one and then do an inplace upgrade through the 2008 installation wizard. That sort of thing tends to give my sphincters palpitations though.
Our Java server application logs data to a SQL database, which may or may not be on the same machine. Currently we use MS SQL Server, and we're now porting to MySQL. A user configures database backup parameters on our app server, e.g. time of day to run a backup, and the app server executes SQL Server's BACKUP DATABASE command at the appropriate time, via a sproc. It does incremental backups daily and full backups weekly.
MySQL lacks an equivalent feature to tell the database from a client connection to back itself up. Options we're considering are:
Create a UDF to shell out to mysqldump (or copy database files), which can be called from our app server via a sproc. Essentially we'd be implementing a version of BACKUP DATABASE for MySQL.
Create a service to run on the MySQL box that can get the backup settings from the app server and run mysqldump (or file copy) locally.
Create a backup sproc to mimic mysqldump, e.g. SHOW CREATE TABLES and SELECT INTO OUTFILE for each table.
Setting up a cron job, Perl script, third-party app or other tricks that'd work great in a data center aren't preferred; this is a shrink-wrap package that needs to be pretty robust and hands off.
Database sizes can range from roughly 10MB to 10GB.
I'm aware of the binary logs for the incremental piece. I figure the general solution will probably apply to them as well, if we decide to use them.
This is all on Windows 2003 32-bit or 2008R2 64-bit, MySQL 5.1.
The UDF option seems the best to me. The UDF Repository (http://www.mysqludf.org/) has mysqludf_sys, which may be all we need, but I thought I'd ask for opinions since after extensive googling it doesn't seem like others have reached the same conclusion, or maybe our needs are just out of the ordinary. Our app is the only thing in MySQL, so I'm not worried about other users having access to our UDF.
Any solutions I'm overlooking? Any experience with using UDFs in such a way?
Thanks,
Eric
For this an other reasons we decided to collocate our application with the database, so this problem became moot.
Often I need to pull the production database of some project to my local sql server to add features, test out stuff etc.
Today my procedure is to create a backup on the production server, somehow get that to my local machine - and then create a new database locally and restore the backup on top of that.
It is a pain, and takes more time than I like - and I would like to think, there must be a better way.
I have access via SQL Server Management Studio to the production database - isn't there an easier way, that requires fewer manual steps?
How do you do it?
Can't think of a quicker way using SQL Sever Management Studio. I'd recommend SQL Compare from Red Gate for synchronising the schema, SQL Data Compare can sync the data, but it's not quick for large databases over the internet.
You can use SSIS and copy objects between these environments, assuming you have a direct connection to the production server.
Another way, it's a must to make regular backups of the production databases, a simple maintenance plan can make a full backup at night, by example. If this is the case here, just request an early backup to the administrators and then mount it into your environment.
One more way, because production data disclosure can involve legal issues, you can just extract the database schema and then use testing data to make any development. This is also the fastest way to get a database.
A new option is to clone the database. Red Gate SQL Clone is one solution, and Windocks provides SQL Server containers with built-in DB cloning support. Full disclosure, I work for Windocks.
Backup and Restore is slow for my databases, so what I do is:
1. Detach production database
2. Copy files to my dev machine
3. Attach database to dev server.
but no body should work on the production database.
My backup procedure is similar - I am detaching the database and archive the files, it is faster than backing up.