I have a SQL Server database (2008) within which I have some CLR DLLs that SQL uses for various things.
Are these DLLs mirrored when I use SQL Mirroring? Our DBA says not, but I find this crazy and cannot find much info on it online.
Is it possible to mirror the CLR DLLs?
CLR Assemblies are stored in the database, and are mirrored as a part of the database. Each database has its own sys.assemblies view, and if you query the master.sys.assemblies DMV, you won't find the assemblies for other databases in the DMV. There are problems that you may encounter with having a database with assemblies in it mirrored. The first being, if you have an External Access or UNSAFE assembly and you used the TRUSTWORTY bit to allow the assembly in your database, this is disabled during the recovery process when you failover, so you have to re-enable it. If you signed the assembly with a certificate you have to create the certificate and login associated with the assembly on the mirrored server manually since this is stored in master, not in the database. The Assembly will be there, and so will your SQL Database Objects, but it may not function. You may also need to change the database owner name as a part of the failover.
http://sqlblog.com/blogs/jonathan_kehayias/archive/2008/03/06/clr-safety-issues-after-database-restore-to-new-server.aspx
If you want to validate what I say above, backup the user database with an assembly on it, and restore it to another server. Your assembly will be a part of the database.
Just to add the obvious point to what Jonathan said: your assemblies have to be deployed in the mirrored application database, not in msdb or some other database.
Related
In short, I need a way to copy a database from one server to another without access to backup functionality, i.e. read and recreate schema and other objects with statements like CREATE TABLE, copy data with INSERT, copy constraints with ALTER TABLE etc...
I have a database on SQL Server in a large enterprise. There is one PROD-like DB and multiple individual developer instances that are supposed to be kept in sync with it by way of running the same migration scripts. However, this is not always done and instances tend to fall behind up to the point where auto-migrate is impossible and manual migrate takes a lot of time.
Normally, we would just restore those databases from a backup, but most rights for managing the databases are reserved for dbas, as a dev I can only read/write schema and data, but not make\restore backups, so this takes a lot of bureaucracy to do. I'm looking for a script or tool to clone PROD-like database without using backup.
P.S. We have SQL Source control from RedGate that we use for part of our migration process, I'm thinking if I could use it somehow?
SQL Source Control isn't the right tool to refresh dev environments from production. If you can't access a backup, you could try using a combination of SQL Compare and SQL Data Compare.
I am registered at Go Daddy and want to restore the database there from my local machine. The tool they provide me with doesn't work unless it's from them. I'm trying to restore from my local SQL server, but when I browse I can't restore the local files of the remote database.
They're intentionally preventing users from restoring backups that are "foreign" to them in order to satisfy an obscure Microsoft security recommendation.
You will have to perform a schema comparison and a data comparison between your local machine and the empty database on the hosting to generate the scripts to re-create all of the objects and data. (Having those scripts available in a source control storage would also be helpful.)
There are basically two ways to restored the Database using Sql Server.
Through SSMS Restore Utility.
Manual Database restore Script from here
I have two SQL Servers and I want to do a backup on one of them and then restore that on the other server. The catch is that the database already exists on the server I'm restoring to, and I want to keep the security settings the way they are on the server I'm restoring to.
The other catch is that I want to do all of this from PowerShell, so no GUI operations.
Or is this maybe the wrong solution to the problem. Is there maybe another way to move the data without doing a backup/restore and keeping the security settings?
In my environment we use Powershell scripts with Red Gate Compare Professional to restore databases and persist security plus database object differences. The process is fairly simple
Create a Red Gate snapshot of the destination database. Using the Red Gate command-line tool. The file it generates is very small and only contain users, permissions, and objects--basically everything except for the data.
Restore the source database over the destination database using T-SQL
Use the command-line Red Gate tools to compare and synchronize snapshot created in step to the nearly restored database. Any security or object changes are restored.
This solution does require purchasing the Professional edition of SQL Compare and installing the tool on the development server from which the script can be executed. All of this can easily be put into SQL Agent job. The use of Powershell is really kind of basic since we're just executing sqlcompare.exe
There is an article here explaining how to script SQL Server permissions through SMO via PowerShell. Your scenario would then be to script permissions from your initial DB before restoring the backup, then execute the generated script after backup has been restored.
We're developing an aspx project with Visual Studio 2010 Professional, SQL Server 2008 R2 and Team Foundation Server 2010. Since the development is being carried out in multiple offices, each developer has their own local instances of the databases.
I want to bring these multiple databases under source control (or at least the schemas of the DB, structure and stored procedures - data doesn't matter to me). My preferred approach is to add database projects to the VS solution, which is already source controlled in TFS. Any changes will be distributed by TFS, and can be deployed locally.
The problem I'm having is that the database projects contain a reference to a local database instance (server & name). When someone gets the latest version of my changes, they will have a reference to my local DB instance (which is different to their local DB instance). They would need to change the DB details (thus checking the dbproj out) in order to get my updates.
So, is there any way that the database server & name can be left out of source control while the schemas remain under source control? Any help would be much appreciated!
I'm not sure if you can. However, you could use an alias, so all of the developers use a database on their local machine, but referenced by the same alias.
Take a look at: http://www.mssqltips.com/sqlservertip/1620/how-to-setup-and-use-a-sql-server-alias/ for how to set an alias up.
That way you can separate the database from the connection details.
I'm involved in developing a unique enforced database source control solution called DBmaestro TeamWork.
It has a plugin to SSMS which allows the developer to work directly on the database objects (change their working environment), run their tests and then perform Check-In which reads the metadata (tables' structure, procedures, functions, views etc.) to the version control repository.
With the Impact Analysis it is easy to merge changes from different databases to a single database.
The impact analysis algorithm perform 3-way analysis (not just a simple compare & sync) to identify changes origin from developerA which should not be reverted when developer merge his changes and it ignores the database name when running the impact analysis or generating the delta script.
I frequently develop small internet applications using ASP.NET and SQL Server 2005. My databases are always only accessed by one application through an ASP.NET web service or something similar.
When I'm developing an application and moving a database back and forth between my development computer (SQLExpress 2008) and hosted server (SQL Server 2005) invariably I end up getting a hodgepodge of owners/roles/schemas/logins etc that seem to crop up and take control of various pieces of the database.
I only know enough about SQL Server to be dangerous, and I just want to get databases designed, but I invariably have to change the db and end up getting various permissions errors (for example when trying to open a diagram after transferring a db).
Is there a way to simply tell SQL Server Management Studio "Hey, I'm the only guy who's going to use this stupid db, so just let me do it?"
Like some command that sets all of these pieces to 'dbo' or something like that?
I am assuming you are using Windows. Make sure you are connecting to SQL with Windows authentication and give your account Sysadmin permissions. Now everything you create (Create Table tablename, Create View viewname) will automatically have dbo as the owner.
Unfortunatly there is a couple of easy answers to your question, but you are probably not going to like them because they will require you to invest in SQL Server skills.
The first tool you should look at is Visual Studio 2008 Database Developer Edition. This version has management tools you are looking for to manage schemas, users, ... I thinks this is now included with Visual Studio 2008 Development Edition
The second approach is to embrace SQL Server administration and get comfertable with writting DDL scripts. The goal is to get to the point where you can deploy changes to SQL Server in a predicatble manner from your development enviornment to test and ultimatly to production.
The crux of the problem is that you move back and forth the database itself. Databases are surprisingly tightly coupled to their host SQL instance, by the login to user mapping and by other settings as well, like encryption keys, usage of msdb procedures and maintenance plans among other. You could minimize some of the impact by carefully using exlclusively SQL Authentication, but that won't eliminate the problem completely. The real solution is that you should have a deployment script and apply changes to your production database(s) via executing T-SQL script(s) that you have previously tested on your development db, not by moving a db 'back and forth'.
I create all objects specifically specifying I want them created as dbo.
so to create a proc I do
Create Procedure dbo.myprocname