Background:
I have a site built in ASP.NET with Sql Server 2005 as it's database. The site is the only site on a Windows Server 2003 box sitting in my clients server room. The client is a local school district, so for data security reasons there is no remote desktop access and no remote Sql Server connection, so if I have to service the database I have to be at the terminal. I do have FTP access to update ASP code.
Problem:
I was contacted yesterday about an issue with the system. When I looked in to it, it seems a bug that I had solved nearly a year ago had returned. I have a stored procedure that used to take an int as a parameter but a year ago we changed the structure of the system and updated the stored procedure to take an nvarchar(10). The stored procedure somehow changed back to taking an int instead of an nvarchar.
There is an external hard drive connected to the server that copies data periodically and has the ability to restore the server in case of failure. I would have assumed that somehow an older version of the database had been restored, but data that I know was inserted 7 days and 1 day before the bug occurred is still in the database.
Question:
Is there anyway that the structure of a Sql Server 2005 database can revert to a previous version or be restored to a previous version without touching the actual data? No one else should have access to the server so I'm going a little insane trying to figure out how this even happened.
Any ideas?
Using SQL Server's built-in backup and restore mechanism, there is no means to pick only certain objects to restore. With transaction log backups, you can restore to a point in time which might be before a certain transaction or ALTER statement was made but that's the closest you get. There are tool's which will let you pick certain objects to restore however they work by either restoring the database to a copy and copying over the objects you want or reading the backup directly and copying out those objects. In other words, this is not something could have happened using the built-in tools accidentally. My guess is that someone accidentally ran an old script of the stored proc(s) that reverted it.
It would be trivial to change a stored procedure without touching any data, or any other stored procedure. How who why when, that's the problem.
One suggestion, run
select * from sys.procedures
and check the create_date and modify_date columns, for both your problem procedure and all other procedures in the database.
I've witnessed similar things happening with an app I have installed at one client location. Every so often the s'procs revert to an older version.
It's just one client, the app is installed at several others which have never had this issue, and they happen to be a school district as well. It happens about once every 3 months or so, and no one should be touching that machine. I'm not even sure they have anyone in house that would know how to open enterprise manager.
Out of curiousity, what backup software is your client using? and, after checking the creation / modify dates on the procedures, did a server reboot occur around that time?
The reason I ask is that my client has backup software that does some really weird things on that server. For example, on reboot it has to "play back" changes, including file operations, since the last successful backup. Also, is it installed in a VM?
Through Data Transformation Services (DTS) ? or if the scripts that set up the database are available someplace..
Related
Recently found out that unknown html codes were inserted into my SQL Server database without my knowledge, it's something like this in every cell
[my original database data]</title><style>.a2vf{position:absolute;clip:rect(475px,auto,auto,475px);}</style><div class=a2vf>These rules are bound <a href=http://paydayloansforsure.com >fast payday loans</a> unscrupulous len...
I initially thought my database password was compromised. So I changed my password to a more difficult one, but after a couple of days, it appeared again. Anyone knows how it got into the database like that and how to prevent it?
UPDATE:
After some investigation, I suspect this might be caused by a software which I downloaded to schedule backup SQL databases. I've reformatted my local machine and start all over again, it did not happened anymore.
After some investigation, I suspect this might be caused by a software which I downloaded to my local machine to schedule SQL databases backup. I've reformatted my local machine it did not happen anymore.
I installed sql server 2005 Express in a virtual clean Windows xp machine.
On the database engine I created two instances, each one of these I have configured mixed authentication and the first user 'sa' password is 'password1' and the second 'password2'.
Then in the first instance, I have created a new database with a common table and a few details. Followed by this stopped the first instance I try to attach the database in the second instance. As it was to be expected, this caused an error and the process was aborted.
Then what I did was to change the password for the 'sa' user and I put the same one that was in the one instance ('passowrd1'). Now try to attach the database, the process is run correctly and the database created in the first instance was properly attached in the second instance.
Until here nothing weird, my surprise was given to make the next step.
In the second instance, I have again changed the password to the user 'sa' and this time put it as it was originally ('password2') and the attached database is kept running.
This is the first thing that I don't understand why it occurs in this way. And as last test, I stopped the second instance and start the first, and to my surprise the database also kept running.
Can someone tell me why this behavior is given as well?
My fear is to create a database with a password 'X' and then for some reason someone discover the password and then changing it, if someone attached database in another instance, can use the old password to open it. The same behavior is happening at others editions of sql server?
Are there any security layer extra that recommend me to apply?
The SA password should have no effect on any user-created databases. It only would affect system databases (Master, Model, MSDB, TempDb). Unless, of course, you encrypted your database files or if you are doing a password-secured backup/restore (which, you are not).
When you were unable to attach the first time, I would suspect that the first SQL instance had not finished shutting down yet. It was merely a coincidence that you took a few minutes to change passwords and then were able to attach the original DB file.
If you want to secure your databases, so they are not stolen and attached to another database, I would recommend doing this at the Server OS level. Prevent people from getting to the file in the first place.
Scenario: System in a VM in Azure using MVC and a SQL Database (not in the VM) working under normal conditions for 2 or 3 months. Suddenly, stored procedures called from my MVC web app or SQL Management Studio return Time Out. Queries like Select * from Table work perfect.
EDIT: Timeouts while executing Alter or Create SP queries happened too.
No proper solutions or explanations found.
Workaround: Restore old backup in a new SQL Database and change the connection string to the new Database. While the system is running in the backup, try to backup the database with issues (first close all connections to that DB like Management Studio). It may take some time and some retries. After the backup is done, restore it in a new DB and change back the connectionString. You will lose a few minutes of data and some downtime but you will have your system working again in Azure.
Any ideas about this issue in the Stored Procedures in Azure?
At first glance, this smells like a parameter sniffing issue; it is probably not related to Azure.
Check this thread for details on what the issue is, and how to resolve it: Parameter Sniffing (or Spoofing) in SQL Server
On my development box, I always run the latest version of SQL Server. I often deploy databases from my dev box to a live/staging area for review or testing. I've done this many times and it has always been a painful process, but I am realizing that I need to find an easier, more reliable and consistent way of performing this basic operation.
I normally use WebMatrix purely for deployment and it's worked fine, but I've been having problems getting it to work on my server for some reason. Consequently, I am seeking an alternative solution.
Creating a SQL dump file would probably work, but it's not an acceptable solution a database contains images and easily exceeds 2 gigs of data which would take forever.
The Import/Export utility fails due to issues with incomplete schema copies, identity inserts and checks. The solutions offered for these issues has failed to work in my particular case.
The Backup and Restore method also fails due to some strange incompatibilities between SQL Server 2008 and 2012. SQL Server 2008 Management Studio throws exceptions during the restore process of a 2012 database. It's odd that this happens, even though I set the compatibility of the database to version 2008.
I haven't tried the Detaching, copying and reattaching files method, but I haven't bothered trying since it would probably fail for the same reasons the backup and restore method did.
Are there other alternatives out there? Also, why is this so unbelievable hard for a task that is so common and important, especially in this day in age of 2013? Get real Microsoft!
We changed our method of deploying and moving databases between servers, instances and versions by adopting the tools from RedGate. They are expensive, but worth it IMHO.
My team creates scripts for ~everything.
Database Creation, Alter, Inserts, etc, etc.
And we write all scripts that check for the existence of things before trying to create them.
Aka, we can run the scripts over and over and get the same results.
And we deploy to different environments by using SqlCmd.exe.
EDIT
See:
http://odetocode.com/blogs/scott/archive/2008/02/02/versioning-databases-views-stored-procedures-and-the-like.aspx
and
http://odetocode.com/blogs/scott/archive/2008/01/30/three-rules-for-database-work.aspx
=============
If that is "too much" then I agree with the other poster, RedGate is your friend.
Points below aside, have you considered the Database Projects within VS2012? they allow you to script off the tables, sp's, triggers, users etc you want, generate sql cmd scripts, make changes and schema compare and version control your database code, I'd certainly recommend it
"Creating a SQL dump file would probably work, but it's not an
acceptable solution a database contains images and easily exceeds 2
gigs of data which would take forever."
Why is this a problem? where are you transferring the file from and to and over what connection?
"The Backup and Restore method also fails due to some strange
incompatibilities between SQL 2008 and 2012. SQL 2008 Management
Studio throws exceptions during the restore process of a 2012
database. It's odd that this happens, even though I set the
compatibility of the database to version 2008"
This shouldn't be an issue if file is created in 2008 prior to restoring. If you create a new DB in your 2008 instance, then take a backup from that and restore it to a 2012 instance with 2008 compatiblity, then you should be able to use it there, back it up from the 2012 instance and restore to 2008 again afterwards.
I have a live database on a shared hosting server. I am making some major changes to my site's code and I would like to fix some stupid mistakes I made in initially designing the database. These changes involve altering the size of a large number of fields, and enforcing referential integrity between tables properly. I would like to make the changes on both my local test server and the remote server if possible.
I should note that while I'm fairly comfortable with writing complex queries to handle data, I have very little experience modifying database structure without a graphical interface.
I can access the remote database in the visual studio database explorer but I can not use that for anything other than data manipulation. I installed Sql Management Studio express last night and after 40+ crashes I gave up - I couldn't even patch the damn thing.
The remote server is SQL 2005 / The MyLittleAdmin web interface is available.
So my question is what is the best way to accomplish these changes. Is there a graphical interface I can use on the remote server? If not is there an easy way to copy the database to my local machine, fix it, and re upload? Finally if none of the above are viable does anyone have links to a decent info on fixing referential integrity via query?
Sorry for the somewhat general question - I feel like I am making this far harder than it should be but after searching / trying all night i haven't gotten anywhere. Thanks in advance for the help. I really appreciate it.
...Also does anyone have a time machine I can borrow- I need to go kick my past self's ass for this.
Usually hosting providers allow you to backup and restore your database, so the easiest way to accomplish the move is to backup your live DB, download the backup file, restore it locally, do all the changes, do a backup of the local db, upload it, then restore it in the live service. Your site should be placed on an administrative shutdown during this time so it does not continue to update the data while you're doing this operations. You have to make sure your local SQL instance is exactly at the same build version (##version) like the hosting provider, otherwise your local SQL may upgrade the database structure and you'll be unable to restore it back on the hosting provider (or you'll be unable to restore in on your local server if your version is earlier than the host's). The MSDN BOL has a detailed guid on how to Copy Databases using Backup/Restore.
An alternative to backup/restore is to detach/attach the database, but I do not recommend this because you need to move both the MDF and the LDF in sync, and they're also larger in size than a backup.
This assumes you can do all the schema changes on your local copy in a wizardly manner, ie. fast and correct. Of course, that is not easy. The recommended way is to prepare in time a script that applies all the transformations needed to reach the new schema. There are tools like SQL Diff, SQL Compare, SQL Delta and other that can generate such a script. Also Visual Studio Database Edition can do this.
How I would do this would be like this:
Ensure I have exactly the same schema on my dev machine as on the live host. If not sure, I can take a backup of the live server and restore it localy. This would be my reference, v1. schema.
Keep the backup of v1. for reference
Start developing a script that changes the schema to my target. Sometimes I need to refresh my memory on script syntax myself, and what I do is I go to the SQL Server Management Studio wizards for the operation I want to do, select all the options in the UI and then select the 'show script options', that will show me exactly the script SSMS is running to accomplish my desired change.
For each change I add to the script, I can test it by restoring the v1. reference backup I have from step 1 and running the script.
Keep iterating on the script, adding one change at a time, until all the needed schema changes are done. After each change, I can test it again like in step 4.
Yourscript should do not only DDL changes to the schema, but also any DML changes needed (modifying reference data, changing values, moving columns between tabels etc).
When the script is ready, I can download a newer backup, apply the script, and upload the updated backup and restore it on the live host. Alternatively you can simply run the script on the live host (after of course you backed it up in case something goes horribly wrong).
In my projects I always rely on scripts to deploy and upgrade the database. In fact I use the database extended properties to store a 'version' of my application deployed schema and in my code I simply roll forward all the scripts that bring the schema to my last version. I have an article on my blog describing this technique: Version Control and your Database.