Is there any way (3rd party product or other method) to do a partial restore to ms crm?
Say a user accidentially deleted an account. Is there anyway to restore just that single account and corresponding notes, activities etc?
We limit users' permissions but inevitably they will have permission to delete some things and will want to get that item from a backup.
Right now the only method I can think of is to restore the .bak file to another db and write a bunch of code using the sdk to re-create the items. Are there any other options?
Red Gate has a tool which will let you restore just certain objects from a database.
Idera has this new virtual database tool where you basically mount the backup as a SQL Server database.
Full disclosure - I haven't used either for this kind of thing - I've always either used audit trails or restored the database and extracted the data manually.
You are correct in that you can only restore to a different database and work from there.
You could then use something like Red Gate data compare to extract the desired rows (14 day trial, but it's worth it's weight in SO Rep anyway)
To be honest, I'd go with
Right now the only method I can think of is to restore the .bak file to another db and write a bunch of code using the sdk to re-create the items.
After all, 'Its the only way to be sure....', not to mention the (extremely) vague chance of another record being created with the same GUID, which would cause assorted 'bad stuff' to happen.
Yes, a small number, but still more than 0...
Related
We're currently using a tool (no way to change this as it is tied to a larger machine) which creates databases (not tables) on a SQL server (MSSQL 2014) on a weekly basis. These are named:
RESULT_201801
RESULT_201802
...
Over the course of one week, those databases will get filled with data until the beginning of a week where the next one will be created.
Now I need to extract specific data from all available databases. The issue which arises is, that I need to have a user which is allowed to read data from each of that databases. I could easily create that user and add it manually but doing this each week monday morning doesn't seem the right thing to do.
Is there a way to have such a user (with read-only permissions) for the whole database server? What would be the correct way to do that? Will I need to resort back to using a script, executed hourly, checking permissions?
What is the best way to backup SQL server schema ??
My schema contains (file-groups ,file streams,tables,relations between tables,constraints,users,...)
I want to backup the schema and its related objects, so I can restore it later to the same database or to a different database that has another schema and objects.
I tried using the file-group backup because it has some restrictions (database must be FULL recovery mode, must backup primary file-group and log), but I want to backup only one schema at a time.
Has anyone any idea to backup schema to file (access or any format) or any way.
You may want to review this document from when Microsoft introduced schemas into SQL Server.
The shortest answer is that databases are the unit for backup and recovery. Schemas are the unit for security.
You should back up the entire database, not just one schema.
Unless you have a really large schema, you can just script it.
In SSMS right-click on your database, then select Tasks - Generate Scripts...
There are some dialogue windows to go through, you can select only certain db objects if you prefer. I'm not sure if this covers file-groups or file streams but all the other db objects you mention are covered. You could try it with just one table to see what happens.
Be careful, on the "Set Scripting Options" dialogue, click Advanced and scroll down to "Types of data to script" in the modal window and ensure that "Schema Only" is selected.
You can script the schema, the data or both. If you db contains a lot of data and you try to script that, it will almost certainly cause SSMS to crash. You've said in your comment that you also want to back up data. This is the only way I know to achieve this without backing up all the other schemas in the db.
Most of the other options are self explanatory. The tool will generate a SQL script. You can run it on a empty db to build up the data structure that you scripted (or just one schema if you prefer)
I hope this helps.
A developer has included a DB password within a stored procedure (rolls eyes). We include a backup of this database with our setup application for new customers. We've updated the stored procedure, but the password is still visible in plain text within the backup file as this includes both the current stored procedure and the original one.
We've cleared transaction history and recreated the log file, but these don't seem to affect historical stored procedure code. Is there some way of removing this from the DB backup?
Thanks very much in advance for any suggestions! We've hunted around and drawn a blank so far.
You could re-create the full db. SSMS will support you under Tasks -> Generate Scripts... But this can be quite a big work to do...
If you are developing with Visual Studio You could think about a data base project to set your database under Source Control and get a scripted master. This makes it easier to re-create the full database and offers many other benefits. Other IDEs will support this too - probably.
You could try to set the db to single-user-mode, set its backup mode to simple, shrink the log file to smallest, shrink database files to smallest and drive a full backup. I've never had this problem, but I'd assume, that doing so, all residues should disappear...
Good luck!
I have Server_A with DB_A and Server_B with DB_B, both of these are remote servers that I have no root access to.
Server_A is SQL 2012 and DB_A is set in Compatibility level 2008
Server_B is SQL 2008 and DB_B is set in Compatibility level 2008, of course.
I need to copy the data, including relationships and keys from DB_A to DB_B. How can this be done?
Using the import or export wizard I've only been able to move the data and all the relationships are list. Please give a guy a hand and teach him something!
One way is to right-click on the source database in SSMS and select Tasks > Generate Scripts. This will show a wizard which when completed will produce a text file with all the SQL statements needed to replicate the database on a new system.
The neat thing about the wizard is that it gives you a set options so that you can decide what is in the final output. So you get to
pick if you just want the data or the table structures or both.
The final result might not be a good option for large databases but it is very portable.
Actually you can back up to a .bak file.
Where you want to restore it is totally up to you.
If it doesn't work for some reason (it should work fine) you can always try to copy your database like so.
These two steps will copy the database intierly. Including the relationships and keys.
This is the only alternative I've found for your problem since you don't have sysadmin rights.
I was wondering what the best approach would be to restoring a single record from an MDF file (generated as backup on the live instance) into the live SQL Server database.
I know about the process of attaching the file to the database and have read quite a bit about completely restoring, but how about selecting a single record from one of the tables and inserting it back into the same table on the live instance?
I could always create the new record from scratch myself based on the resulting row from the select statement, but I am sure that there has got to be a smarter and cleaner approach to such a simple task.
Thanks a bunch in advance, looking forward to your answers.
Cheers.
You cannot simply read a record out of an MDF file, you need to attach it or restore it to a database.
Natively, you can't. However, Red Gate has a product called Virtual Restore that allows you to mount a database from a backup.
Is this for right now or for future planning? If the latter, then you can utilize database snapshots.
Depending on what kind of flexibility you have on the live server, you could always just attach the backup database under a different name on the live or another linked server and then just select the record you want straight in to the equivalent table in the live database.
How viable this is depends entirely on the primary key. If it is an auto-generated identity column, selecting it in will give a different primary key which may have undesirable results on any linked records you may also want to add, the new primary key would have to be taken in to account.
Example of query
insert into originaldb.dbo.Persons
select * from backupdb.dbo.Persons where PersonId = '654G'
originaldb.dbo.Persons is the original table that you want to select into.
backupdb.dbo.Persons is your restored backup table.
You'll need to modify this query a little if you are not selecting the entire row but that is the gist of it.