Background:
We are running a web application where each user has a login to the system. The application login is mapped to an actual SQL Server 2005 login (which we needed to create). Our development and disaster recovery sites are simply copies of this setup. On a nightly basis, the production database is backed up, the dump is archived, and we restore dev and DR using this file. When this is done, we need to run sp_change_users_login for each user to remap the database user to the SQL login.
Problem:
When the user changes their password on production, the SQL login password is changed. This is not getting synced to dev/DR, so if they try to log on to one of those sites, they can't, and need to reset their password. Is there a [good] way to keep these SQL logins synced across multiple installs?
The next version of this product eliminates the SQL login need, but upgrading is not a current priority.
Script the logins with the password hashed and then drop and re-create them on your target server after you drop the database and before you restore the database back-up. That's how we script SQL2005 logins with our scripter software. You might like to try the software - www.dbghost.com - or build your own solution.
Solution:
This is a follow up to markbaekdal's answer. Here's how I did it:
I run the following against the production database:
SELECT 'ALTER LOGIN ' + CAST(name AS VARCHAR) + ' WITH PASSWORD = ', password_hash, ' HASHED;'
FROM sys.sql_logins
JOIN mydatabase..mytable
ON mycolumn = name
GO
and pipe it through "findstr ALTER" (ah, windows) to a file named loginUpdates.sql. I then run that file against the development and DR databases. It works like a charm.
If you want to get really hardcore, here's a support article a coworker of mine found:
http://support.microsoft.com/kb/918992.
Related
I've been running into an issue in R Studio with a SQL connection.
We've had an on-prem SQL Server that's been upgraded over the years, and a colleague that set it up no longer is with the organization.
We also have an Azure Server that's loaded with a SQL Server as well that was much more recently set up before they departed.
We have a GUI program we're currently developing, and one of the early steps is a SQL Login connection for the user where the variable is declared (db_user) and changes with their login and passes the password correctly within system variables defined in .Renviron as posted on RStudio's site for references.
Our initial connection string looks like this, and this is the line of code that starts the connection and where I believe the issue may lie first:
db_conn_onprem <- DBI::dbConnect(odbc::odbc(),
Driver = "SQL Server",
Server = Sys.getenv("server"),
Database = Sys.getenv("database"),
UID = Sys.getenv("db_user"),
PWD = Sys.getenv("PWD")
Whenever the Azure connection succeeds, it connects as dbo#Azure\Azure vs On-Prem's guest#Server\Server.
(I can't post in-line screenshots yet)
On-Prem Connection Screenshot: https://i.ibb.co/PmbGt5y/RStudio-SQL.png
Azure Connection Screenshot: https://i.ibb.co/WFY3FqZ/azure1.png
I feel this is something dbo-related since that's where the connection drops.
(variable names anonymized)
Now for the issue:
Whenever we attempt to run a series of queries, our on-prem errors out with this:
Error: nanodbc/nanodbc.cpp:1655: 42000: [Microsoft][SQL Server][SQL Server]Cannot execute as the server principal because the principal "db_user" does not exist, this type of principal cannot be impersonated, or you do not have permission.
<SQL> 'EXECUTE AS LOGIN = 'db_user' SELECT name FROM master.sys.sysdatabases WHERE dbid > 4 AND HAS_DBACCESS(name) = 1 ORDER BY name ASC'
However, run the exact same procedure on the SQL Server in Azure with relatively no major configuration, and it succeeds.
Here's the SQL Code we run:
EXECUTE AS LOGIN = 'db_user' SELECT name
FROM master.sys.sysdatabases
WHERE dbid > 4
AND HAS_DBACCESS(name) = 1
ORDER BY name ASC
I feel like I've exhausted my resources for this, first I thought it was the initial R code or possibly SQL Drivers, however I don't believe that to be the issue since the SQL driver pulls a list of names in R Studio in the Connections context menu, but bounces back the error when attempting to complete the query.
Whenever I'm searching errors for references for this error, I see
Cannot execute as the server principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission.
Listed as the most commonly related error for the one I'm experiencing, however I've tried a number of those (From blank DB ownerships to unrelated solutions), but I've mostly hit a wall here.
Any assistance would be greatly appreciated.
I feel this is something dbo-related since that's where the connection drops, but I have no clue where to continue going on this issue.
Yep.
This
EXECUTE AS LOGIN = 'db_user'
requires impersonate permission for the login. Which the error message is clearly telling you. It's unclear why you want to impersonate that login instead of simply connecting as the login to begin with.
I created these tables on sql developer using the default role scott (which I enabled during Oracle 11gs installation)
However when I login from scott using sqlplus the tables don't show at all.
I even tried logging on using connect /as sysdba the tables still don't show up even though I'm connecting via the sysdba role.
I created these tables a week ago and did not initially type the keyword commit when I created these tables however if that was the issue why are they still being displayed on SQL developer every time I log in. Also I think SQL developer auto commits changes when I close it.
And yes these aren't empty tables they do have data in them respectively.
My db is on my local machine and I'm using Oracle 11g so I don't understand what the problem is. Any help would be appreciated.
So my problem was that i was connected to the SID orcl on sql developer
and my sql plus was connected to my SID that i named during the 11gs installation
ran this on sqlplus=
var OHM varchar2(100);
> EXEC dbms_system.get_env('ORACLE_HOME', :OHM);
> PRINT OHM // ---> ORACLE_HOME
to find my oracle 11gs home directory
there was a file called 'tnsnames.ora' it was located at [Your_ORACLE_HOME]/Network/Admin.
Opened it using Notepad( any text editor should work )
In tnsnames.ora file found the service name which i entered into sql developer and changed the port which was mentioned in the .ora file
works like a charm now.
Here is a link to a useful post that helped me achieve my conclusion
https://dba.stackexchange.com/questions/121251/sqldeveloper-ora-12505-tns-listener-does-not-currently-know-of-sid-given-in-co
credits to Do Long Bien
There are two administrative accounts (Server admin and Active Directory admin) that act as administrators. My requirement is to find out the names of these accounts. I have looked into sys.database_principles view and sys.sql_logins view but could not find anything relevant to the same. From SQL query i could not find any helpful system view to fetch the information. Can anyone please help me here?
You can use the TSQL script below to get the Server Admin and Active Directory Admin account names.
SELECT [name], [type], [type_desc], [authentication_type], [authentication_type_desc] FROM sys.database_principals
WHERE (type = 'S' AND [name] != 'dbo' AND authentication_type = 1) OR
(type = 'X' AND authentication_type = 4)
Important Note:
You need to run the TSQL against the master system database
Use the latest version of SQL Server Management Studio
Alternatively, you can get both account names from the Azure portal as shown below.
Reference: Controlling and granting database access
I am trying to create a database using SQL Server Management Express.
The following error occurs:
TITLE: Microsoft SQL Server Management
Studio Express
Create failed for Database
'dbTestDBase'.
(Microsoft.SqlServer.Express.Smo)
For help, click:
http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=9.00.2047.00&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Create+Database&LinkId=20476
ADDITIONAL INFORMATION:
An exception occurred while executing
a Transact-SQL statement or batch.
(Microsoft.SqlServer.Express.ConnectionInfo)
CREATE DATABASE permission denied in
database 'master'. (Microsoft SQL
Server, Error: 262)
For help, click:
http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=09.00.1399&EvtSrc=MSSQLServer&EvtID=262&LinkId=20476
Run Microsft SQL Server Studio as administrator....your problem will be solved
It's very clear: the credential you are using doesn't have enough privileges to be able to create a new database. Are you logged in using Integrated Windows Authentication or Sql Server Authentication? Make sure your credentials have the dbcreator role either way.
http://msdn.microsoft.com/en-us/library/ms176014%28v=SQL.90%29.aspx
If the computer is part of Domain. Log-in as local administrator account on the work station (maybe because the MSQSQL is installed on the computer using local administrator account, means that the local administrator account has systemadmin access on SMSQL), then when you are already logged as local administrator. open the MSSQL , now add/edit MSSQL security account.
I had this same problem. but solved!
you should go to your specify folder where database created (ex:C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA)
then right click on data folder -> properties-> advanced
then uncheck compress content to save disk space.
that's it.
Well, the error message seems to be pretty clear:
CREATE DATABASE permission denied in
database 'master'.
Obviously, the user account you're using doesn't have the permission to create a new database. Is that possible? What kind of user are you using?
Also: can you show us the CREATE DATABASE statement you're using??
Just check whether path is specified or not
For example : "C:..\MSSQL\DATA", in both the columns of Database files in the New Database wizard
I hope this solution will help someone!
My problem started when I had deleted the previous user from PC Management and from registry. Then I create a fresh-std user. and trying to create database from the new user, and that's where my problem started.
After searching for the better solution, I conclude by Uninstalling MS Server Express Database completely from my PC and re-install it again. This save time and solved my problem.
I hope this solution helps someone too!
I had similar issue and was solved by executing below command
--Step1 Find if it is used by some other PID
Use
master
GO
IF
EXISTS(SELECT request_session_id FROM
sys.dm_tran_locks
WHERE resource_database_id =
DB_ID('Model'))
PRINT
'Model Database being used by some other session'
ELSE
PRINT
'Model Database not used by other session'
-- Step 2 - Identify
SELECT request_session_id FROM
sys.dm_tran_locks
-- Step 3 Get PID
WHERE resource_database_id =
DB_ID('Model')
-- Step 4 Get the EventInfo
DBCC InputBuffer(214)
-- Step 5 Kill the PID
Kill 214
Hope this helps
I had the same problem when trying to create the database with Right Click + New Database on Databases.
The solve was using New Query and the command to create database:
CREATE DATABASE databasename;
In the end I want to mention that I was logged in Management Studio with (localdb)\v11.0 over windows authentication.
We have a system with an Oracle backend to which we have access (though possibly not administrative access) and a front end to which we do not have the source code. The database is quite large and not easily understood - we have no documentation. I'm also not particularly knowledgable about Oracle in general.
One aspect of the front end queries the database for a particular set of data and displays it. We have a need to determine what query is being made so that we can replicate and automate it without the front end (e.g. by generating a csv file periodically).
What methods would you use to determine the SQL required to retrieve this set of data?
Currently I'm leaning towards the use of an EeePC, Wireshark and a hub (installing Wireshark on the client machines may not be possible), but I'm curious to hear any other ideas and whether anyone can think of any pitfalls with this particular approach.
Clearly there are many methods. The one that I find easiest is:
(1) Connect to the database as SYS or SYSTEM
(2) Query V$SESSION to identify the database session you are interested in.
Record the SID and SERIAL# values.
(3) Execute the following commands to activate tracing for the session:
exec sys.dbms_system.set_bool_param_in_session( *sid*, *serial#*, 'timed_statistics', true )
exec sys.dbms_system.set_int_param_in_session( *sid*, *serial#*, 'max_dump_file_size', 2000000000 )
exec sys.dbms_system.set_ev( *sid*, *serial#*, 10046, 5, '' )
(4) Perform some actions in the client app
(5) Either terminate the database session (e.g. by closing the client) or deactivate tracing ( exec sys.dbms_system.set_ev( sid, serial#, 10046, 0, '' ) )
(6) Locate the udump folder on the database server. There will be a trace file for the database session showing the statements executed and the bind values used in each execution.
This method does not require any access to the client machine, which could be a benefit. It does require access to the database server, which may be problematic if you're not the DBA and they don't let you onto the machine. Also, identifying the proper session to trace can be difficult if you have many clients or if the client application opens more than one session.
Start with querying Oracle system views like V$SQL, v$sqlarea and
v$sqltext.
Which version of Oracle? If it is 10+ and if you have administrative access (sysdba), then you can relatively easy find executed queries through Oracle enterprise manager.
For older versions, you'll need access to views that tuinstoel mentioned in his answer.
Same data you can get through TOAD for oracle which is quite capable piece of software, but expensive.
Wireshark is indeed a good idea, it has Oracle support and nicely displays the whole conversation.
A packet sniffer like Wireshark is especially interesting if you don't have admin' access to the database server but you have access to the network (for instance because there is port mirroring on the Ethernet switch).
I have used these instructions successfully several times:
http://www.orafaq.com/wiki/SQL_Trace#Tracing_a_SQL_session
"though possibly not administrative access". Someone should have administrative access, probably whoever is responsible for backups. At the very least, I expect you'd have a user with root/Administrator access to the machine on which the oracle database is running. Administrator should be able to login with a
"SQLPLUS / AS SYSDBA" syntax which will give full access (which can be quite dangerous). root could 'su' to the oracle user and do the same.
If you really can't get admin access then as an alternative to wireshark, if your front-end connects to the database through an Oracle client, look for the file sqlnet.ora. You can set trace_level_client, trace_file_client and trace_directory_client and get it to log the Oracle network traffic between the client and database server.
However it is possible that the client will call a stored procedure and retrieve the data as output parameters or a ref cursor, which means you may not see the query being executed through that mechanism. If so, you will need admin access to the db server, and trace as per Dave Costa's answer
A quick and dirty way to do this, if you can catch the SQL statement(s) in the act, is to run this in SQL*Plus:-
set verify off lines 140 head on pagesize 300
column sql_text format a65
column username format a12
column osuser format a15
break on username on sid on osuser
select S.USERNAME, s.sid, s.osuser,sql_text
from v$sqltext_with_newlines t,V$SESSION s
where t.address =s.sql_address
and t.hash_value = s.sql_hash_value
order by s.sid,t.piece
/
You need access those v$ views for this to work. Generally that means connecting as system.