I have restored a database for an application that uses SQL Server logins for security. The restore is complete and functional, although there is a small issue.
The database users are present (Server->Database->Security->Users) but they are not present in the server logins (Server->Security->Logins). This is because I restored the DB on a different server than where the backup was taken.
So it seems I cannot reset their passwords anymore. AFAIK, you can only do this from Server->Security->Logins and not from the database security itself.
Is there anyway to quickly "synchronize" the whole thing so users show at both places ?
Thanks.
Related
Is there a programmatic way to validate that that restored database from an Azure SQL PITR backup is valid?
What have I tried
I know the domain entities that are stored in the database and can verify if certain tables have entries from a specific period. However this seems to be too dependent on the type of data we are storing
Is there a system based way to do this comparing audit / transaction logs. I am not a database administrator and might not have the correct terms to explains the problem.
Question
How do I validate that the database X I restored from a database backup went smoothly. Is there a checklist that I can check to ensure this that does not rely on the actual table definition (timestamps columns)?
I backed up a database from a SQL Server 2008 and restored it to my local machine using SQL Server 2012, now I'm trying to login to the server with the copied database user account and I wasn't able to do so.
After googling the issue I found that I have to change the user type from SQL User Without Login to SQL User with Login but the drop-down list is disabled as you can see in the picture below, how can I fix this and is this is the best way of doing what I need to accomplish or do I need to add this user to the server level?
I remember running into this before when doing backup / restore across servers. Basically it comes down to how SQL Server works. There's SQL Server users & there's database users (SQL Server users who are database users are represented via mappings). They are however not the same thing.
A SQL Server user belongs to the SQL Server, a database user ONLY belongs to the associated database. What happens when you have a database user, but not a SQL Server user? You can't login to SQL Server non-obviously.
Thereby what I do is after moving the database, I add the user I need to login as to SQL Server users using SSMS, remove the old database user (it's got dependencies associated w it that prevent mapping to it) & lastly make a new user on the database by mapping my SQL user to the database w appropriate permissions.
This approach is by no means elegant, but it works 100% of the time w no code needed, & you should consider a more permanent system if you have automated backup / restores happening. For the one off, this is how I've always done it.
Problem
Is it somehow possible to create a Windows Authentication login for a SQL database without performing a check for the user at creation time?
Example
Consider ServerA that exists in our DomainA, and ServerB that exists in the customer's DomainB. Being separate companies, DomainA and DomainB never share resources. But, if we backup from ServerB and restore to ServerA, we are able to see the existing SQL logins for users from DomainB, and even modify and code against these logins. This is good, because we are able to develop the database schema on ServerA and then publish to ServerB.
But, if I want to add a new user for this database, and am working on ServerA in DomainA, the following command produces an error:
CREATE USER [DomainB\User];
Windows NT user or group 'DomainB\User' not found. Check the name again. (Microsoft SQL Server, Error: 15401)
This is bad, because we're no longer able to develop on ServerA using the same schema as ServerB.
Backstory
I'm attempting to bring our database-driven application's database schema into source control using a Visual Studio 2010 Database Project. It's important to me to make this work well enough to convince the boss not to continue using 60-GB database backups in a zip file as a means of 'Version Control' (especially since this is just for schema, and not a backup routine). VS2010 DB Projects use scripting to create/modify databases, and so they can't create WinNT users for an unknown domain. In order to get the boss's buy-off, we're going to have to be able to match the capabilities of restoring a backup, and that means being able to re-create users for domains that we don't have access to.
Using SQL Server 2008 in my case.
Note - DBProjects are best suited to managing and versioning your SCHEMA, not your data.
If you want to keep rolling backups of your SQL databases as a whole, then I'd recommend a decent backup strategy.
If you want to better manage your databases' evolving schemas, then using DBProjects may well be your best bet.
FWIW, if you reverse-engineer a DB into a DBProj, you could then run a script to replace DomainB\known-user with DomainA\known-user prior to deploying within DomainA, no?
No, because SQL needs to know the windows SID (ugly GUID) of the user at the time it's created.
Note that you can, however create a SQL or Windows User with the same name and password as your remote SQL, Machine, or Domain user, and it will be able to log in.
We have set up a logshipping scenairo on 2 Sql Server 2005 machines. The secondary database is in STANDBY mode.
We want to use this secondary server for reporting purposes, as the report viewers will query this STANDBY database according to their given execute rights. So we need multiple users on this secondary server, having different execute rights on the STANDBY database.
The problem is, after seting up log shipping, we can't grant the necessary permissions to the standby database as it is read-only.
Do you have any suggestions ?
Thanks,
Umut
For some reason, till we setup a better reporting system, we need to use the Standby server for reporting purposes.
And there is a way to create new users and give necessary sp execute rights to that user on the standby server.
The simple solution is, to create a login on the primary server and Select its SID from master table. Then with "sp_addlogin" create the same login with the same SID on the Standby database.
Then, on the primary server give required rights to the user on the database. With the restored transaction logs, the execute rights will ship to standby server. Passwords don't need to be the same on two servers, so the standby report viewer user can't access the primary server with the same credentials.
Sadly, you need to look into something other than log shipping.
Log shipping works by keeping up-to-date copies of your logs in a 'continually' restoring/recovery state on the secondary server. As such, the database there is never actually 'active' or live - as it's always just applying more and more logs and waiting for the command that will make it go active.
In other words, log shipping is ONLY for high-availability - it does NOT support duplication of your data in USABLE form.
To learn more about what purpose logging serves, check out this video:
http://www.sqlservervideos.com/video/logging-essentials/
And if you really need a secondary server for reporting purposes, then I'd suggest using something like transactional replication. (It's NOT suitable for high-availability solutions because of some of the schema changes and limitations you'd have to make... but it does work well as a way to 'publish' multiple copies of your database to different servers/locations for reporting purposes.)
I am having a problem with one database on my SQL Server 2005 production server.
A number of databases are already set up for mirroring, however when I right click and go to properties in SSMS, on one particular database there is no "Mirroring" property page available.
I have done the normal tasks, such as setting Full Recovery model, running a full backup of the database and backing up the logs.
I can't see that this is a server specific issue as other databases are happily mirroring.
I've looked around and I can't see that I'm missing a setting, any help would be appreciated.
Thanks.
EDIT: This is nothing to do with the Mirror Database yet, I can't get as far as specifying the Mirror Database , I cannot see the "Mirroring" page on the principle.
EDIT: I have managed to setup mirroring using t-sql commands. However I am still unable to see the "Mirroring Page".
UPDATE: This applies to the Transaction Log Shipping option as well. I can successfully set it up in SQL but not through SSMS.
Check theese items:
2 . The mirror database has to be created from a full backup of the principal server and should be restored in "Restore with Norecovery" model. It is followed by a restore of transaction log backup of the principal database so that the log sequence numbers of the mirror and the principal database are in synch with each other.
3 . The mirror database must have the same name as the principal database.
...
8 . DB Mirroring is available in Enterprise, Developer and Standard Editions, however, please refer to Microsoft website for a comparison chart as some features are not available in the Standard Edition. SQL Server Workgroup and Express Editions can only be used as witness servers.
Database Mirroring in Microsoft SQL Server 2005
Test monitoring with sp_dbmmonitorresults (Transact-SQL)
I don't have the answer, but I ran across the same symptom yesterday, and I remembered your question here, hahaha. My problem was that I set up database mirroring using the wizards, but one of the systems had a firewall blocking the mirroring port. The wizard setup went all the way to the final part of enabling database mirroring, and then errored out - but at that point, mirroring was already set up. Mirroring worked great, but there was something in the database metadata that wasn't set quite right. Even when I removed the firewall, parts of SSMS acted as if mirroring wasn't set up for that particular database, even though it was.
I then set up additional databases for mirroring (with the firewall off) and they worked great. My solution was to remove mirroring on that database and then add it again, and it worked fine. Doesn't sound like that's worked for you, though.
I ended up having to have a Microsoft Support call for the problem I was facing. Anyway after sometime and a number of support sessions they worked out that the database with the problem had an ID of 4 in sys.databases. IDs 1-4 are usually reserved for the system databases and if a database has any of these ids the T-log or Mirroring properties are not displayed. So somehow our database got the ID 3 and now I better get on and detach and reattach some databases to reassign IDs.