|
Fair enough....
a) SQL 2008 R2.
b) Updates probably will be weekly, but could be more often.
c) Production DB is in Winnipeg Canada. I am in development in Southern California.
d) Data will be in use immediatley in Canada.
If it's not broken, fix it until it is
|
|
|
|
|
We use Red-Gate SQL compare for deployment of scripts (schema changes). If we have to move any data into production it is a 3 week process with multiple sign offs and blood on the table.
You could set up and automated deployment process that would:
take a backup of the production
script the changes (Red-Gate)
copy the scripts to the production server
run the scripts on production
take a backup of the production
FTP it to the dev server
restore the production backup to the dev server.
However I would shoot the person who suggested you automate this, I want someone hand holding the processes at every step, oversight and someones balls at risk if production goes down.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: However I would shoot the person who suggested you automate this, I want someone
hand holding the processes at every step
really ? thats a bit drastic isnt it .. if you cant afford a decent replication scheme, do you want to be a slave to manual methods ? different strokes for different folks I guess
We use disk level mirroring between prod and d/r - an initial mirror is replicated to our d/r site over dark fibre - that has its issues as well - if the prod mirror is corrupted, then, so is the d/r mirror (thats a basic level explanation, its a bit more complicated) .. my point is, not everyone has the $$ for big buck solutions, or the need, but I would automate a 'simpler' process as much as possible (caveat) with the appropriate checks and balances and control-points, and, everything has different 'angles'/pitfalls ..so know the weak points of a solution
'g'
|
|
|
|
|
Actually I was talking about the automated deployment TO production, that is something I would not want to do, the process yes but not the initiation of that process.
Replication and backup distribution of the production database is something I would highly approve of if I could get it, policy, the f***ing god POLICY will not allow production data in dev. Ah well you work in finance you have to abide by their rules  .
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
sorry - my fault
production data in dev - yeah, a tricky one - we have a process that 'washes the data'/ anonymizes it
'g'
|
|
|
|
|
Garth J Lancaster wrote: we have a process that 'washes the data'/ anonymizes it
And I still need a dispensation from the god Policy to get the data!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
You are going to be doing structure and data changes to a production database on a weekly basis?
And I can only suppose that there is other software that uses it which will also need to be updated.
Certainly not something I would want to see.
Better make sure that you have complete automated unit and system testing.
And have a lot of time to dedicate to implementing the automated deployment and providing for a rollback for ALL systems.
I doubt you will find a tool that does it all. And every database change will need to be evaluated for rollback impact.
|
|
|
|
|
Hello!
We are trying to refresh our development environment with data from QA server. Our QA server is located outside our network in a remote location.
What is the easiest way to copy over data from QA server to our development server?
Currently, following the back up database, and trying to copy over that file to restore it.
any other way?
Many thanks!!
|
|
|
|
|
It has been my experience that, although painful, doing a backup and then a copy or FTP is the best solution available.
I have previously been required to back up the production database and sent it via FTP to the vendor to reproduce a given problem.
|
|
|
|
|
Yep.
I agree with Tim. 
1) backup the database
2) FTP it to the desired location
3) restore database
You may want to perform a data compression on the backup, but sometimes it doesn't really compress.
|
|
|
|
|
Perfect, i also follow that
|
|
|
|
|
Agree.
Zip/compress it before send also.
|
|
|
|
|
7-zip usually seems to produce smaller results than regular zip files. On one server, it compressed a 1.3Gb backup file to 55Mb, which took the nightly FTP transfer down from 7 hours to around 15 minutes.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Yes, once zipped - the file size from 2 GB has come down to 850MB.
I am trying to do a copy of the file from remote server, literal right click copy, and right click paste on to my laptop. I keep losing the connection.
If we use a FTP tool, would this be the same issue, of losing the file transfer connection?
Thanks for all the ideas and suggestions.
|
|
|
|
|
FTP tends to be more robust than copy+paste in Explorer. However, if you have underlying network problems, you'll still have problems with FTP transfers.
I'd be inclined to give 7zip[^] a go - the maximum compression settings will take a bit longer, but they should be able to get the file size down a lot further.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
vkEmerson wrote: I keep losing the connection.
With a one-shot you just keep trying.
But if this needs to happen on a frequent basis then you should look into getting a restartable transfer mechanism in place.
|
|
|
|
|
Hi,
I would like to ask how would you decide if you are developing a hospital management software using C# .NEt and MySQL if you should go for myisam or innodb?
Thanks,
Technology News @ www.JassimRahma.com
|
|
|
|
|
Jassim Rahma wrote: a hospital management software using C# .NEt and MySQL
Why MySQL if you're using C#? What platform are you on?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
InnoDB
You would only choose myisam if you have very specific requirements and if you analyzed the difference and determined that InnoDB would make it impossible.
|
|
|
|
|
Neither, I would start by doing a proper review and analysis of the requirements and then decide which database system would have the features and power to support it. And for a hospital system I doubt that anything less than Oracle or SQL server would be sufficient. It is never a good idea to design your system so that it fits your choice of database and development language.
Use the best guess
|
|
|
|
|
What is SQL injection attack...?
|
|
|
|
|
|
|
Don't thank me, just read the article I linked.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
SQL injection is a technique often used to attack data driven applications. This is done by including portions of SQL statements in an entry field in an attempt to get the website to pass a newly formed rogue SQL command to the database (e.g., dump the database contents to the attacker).
A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.
See also: http://xkcd.com/327/[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
