How could I add some items to the tempdb anytime SQL Server starts up?
I'm no expert at this, but our ASP SessionState is stored in the DB and for some reason the tempdb items used for the session state get dropped anytime the server restarts. Not only do I need to recreate the items, but I also have to recreate the User mappings to tempdb. I have a script that does it, but I can't figure out how to run it on SQL startup
-- Use TempDB
use tempdb
go
-- Create Temp tables if they don't exist
IF NOT EXISTS(
SELECT 1 FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE='BASE TABLE'
AND TABLE_NAME = 'ASPStateTempSessions')
BEGIN
EXECUTE [ASPState].[dbo].[CreateTempTables]
END
-- If ASPSessionState user isn't mapped to temp db, map it
IF IS_MEMBER('ASPSessionState') IS NULL
create user ASPSessionState from login ASPSessionState
-- Give ASPSessionState user read/write permissions to tempdb
exec sp_addrolemember db_datareader, ASPSessionState
go
exec sp_addrolemember db_datawriter , ASPSessionState
go
Um, if you've used the standard settings to enable ASP.Net session state in tempdb, the system should have generated a stored proc (ASPState_Startup) as follows in the master database. This stored proc is configured to run automatically on SQL Server startup:
USE master
GO
DECLARE #sstype nvarchar(128)
SET #sstype = N'sstype_temp'
IF UPPER(#sstype) = 'SSTYPE_TEMP' BEGIN
DECLARE #cmd nchar(4000)
SET #cmd = N'
/* Create the startup procedure */
CREATE PROCEDURE dbo.ASPState_Startup
AS
EXECUTE ASPState.dbo.CreateTempTables
RETURN 0'
EXEC(#cmd)
EXECUTE sp_procoption #ProcName='dbo.ASPState_Startup', #OptionName='startup', #OptionValue='true'
END
So, the temp tables should be being recreated anyway, unless something has been altered since installing.
If additional permissions are required, I'd look to extending the existing CreateTempTables procedure in ASPState.
If this isn't working correctly, you might try using the aspnet_regsql command (found under %Windir%\Microsoft.Net\Framework\<framework version - to remove then re-add session state support to the server. You'd want to use -ssremove then -ssadd, but I'd suggest passing /? first to see all of the applicable options.
Related
How can I parameterise a SQL REVOKE command?
DECLARE #ViewName nvarchar = 'MyViewName'
DECLARE #UserRole nvarchar = 'MyRoleName'
REVOKE SELECT ON [#ViewName] TO [#UserRole]
Outputs the following error:
Cannot find the object '#ViewName', because it does not exist or you do not have permission.`
Do I need to use Dynamic SQL to solve this or is there another way?
My actual Use Case is in ASP.NET SqlDataClient and the code is being generated, so I have limited control over it. The code being sent to SQL (sniffed by SQL Profiler) is:
exec sp_executesql N'REVOKE SELECT ON [#ViewName] TO [#UserRole]',N'#ViewName nvarchar(24),#UserRole nvarchar(12)',#ViewName=N'MyViewName',#UserRole=N'MyUserRole'
Because GRANT and REVOKE require considerable permissions themselves, it's usually attractive to do this in a stored procedure that builds the dynamic SQL and can execute the commands under a different credential. That way you can selectively assign the right to REVOKE by controlling access to the stored procedure, add auditing if this ever becomes a requirement, and last but not least you can keep using parameters.
In this case:
CREATE PROCEDURE dbo.RevokeSelect(#ObjectName NVARCHAR(128), #RoleName NVARCHAR(128))
WITH EXECUTE AS OWNER AS BEGIN
SET NOCOUNT ON;
DECLARE #SQL NVARCHAR(MAX);
SELECT #SQL = REPLACE(REPLACE(
N'REVOKE SELECT ON #ObjectName TO #RoleName;',
'#ObjectName', QUOTENAME(#ObjectName)),
'#RoleName', QUOTENAME(#RoleName))
;
-- For debugging
--PRINT #SQL
EXEC (#SQL)
END;
GO
GRANT EXECUTE ON dbo.RevokeSelect TO [application_login];
Thanks to EXECUTE AS OWNER, the [application_login] account needs no additional permissions; it can REVOKE SELECT on any object in the database through the stored procedure. This can be exactly what you want, but if it's not, you should remove EXECUTE AS OWNER and grant individual CONTROL permission on the objects (but this, of course, allows lots of other operations as well).
Take care that a procedure that performs dynamic SQL needs careful review to ensure it's not susceptible to SQL injection, just like anything else that uses dynamic SQL. Obviously this is even more important if the procedure uses EXECUTE AS OWNER, since it could do anything. In this case, applying QUOTENAME to both parameters takes care of that.
Last but not least, while EXECUTE AS OWNER is simple and convenient, it will fail if the database owner is not an account but a group. In this case, if you want to delegate permissions, you'll have to create a proxy account for use in EXECUTE AS or sign the stored procedure with a certificate. You may want to do this anyway if developers can't be trusted with the power of EXECUTE AS OWNER. That goes beyond the scope of this answer, but Erland Sommerskog has an excellent writeup on this topic.
I copied a database from a live MSSQL server to my local one, and was able to log in correctly. I am having a problem however in that when it is time to call a stored procedure the Asp.Net application keeps telling me the SP does not exist, when it clearly does.
I am using windows authentication but on the server I was using credentials, could this be the problem?
Also, all of the SP's have my online username attached to their name, as in username.StoredProcedurenName.
Please help I have been trying to fix this for hours.
I just noticed that when I attempt to run the SP from the SQL Management Studio it works, but it appends the username to the SP such as:
USE [DBNAME]
GO
DECLARE #return_value int
EXEC #return_value = [username].[SPNAME]
SELECT 'Return Value' = #return_value
GO
If I remove the username, it says the same thing (SP not found). How do I get around this?
I suspect you are calling your stored procedure without specifying the schema. When calling a stored procedure (or accessing a table, view, etc) that's not in the default schema that your account is configured for, usually dbo, you need to explicitly include the schema like the sql command below
SqlCommand cmd = new SqlCommand("username.StoredProcedurenName", mySqlConnection);
It's likely what Jason said. The solution has to do with rights and ownership. When you see the SP in the SQL Management Studio, under Programmability->Stored Procedures, your SP should have a prefix like "dbo." or "GateKeeper."
If the SP has "dbo." as the prefix, the user account with which you're connecting to the DB just be part of the database owners (dbo) group, otherwise you won't have access to it. So, you can either add the user to that group, or create the stored procedure ("create procedure spBlahBlah as ..") using the account to plan to run the program under; when you call it you use "exec GateKeeper.spBlahBlah" to stipulate the Schema.StoredProcedureName.
Those are your two choices.
Is it possible to do
alter session set current_schema=MySchema;
inside a package?
Our asp.net web application call Oracle packages. We'd like to connect to database with an Oracle user that is not the owner of MySchema. For that, we grant execute permissions on Other_User to package MyPackage.
Example:
grant execute on MySchema.MyPackage to Other_User
But when web app connects to Oracle and try to execute the stored procedures of MyPackage, it gets errors because tables don't belong to Other_User.
One way to avoid errors is creating synonyms, but we would prefere to use
alter session set current_schema=MySchema;
if possible, inside the package.
EDIT: When trying to put "alter session" in package:
You cannot use DDL statements (which ALTER SESSION is) directly in PL/SQL.
You need to use an EXECUTE IMMEDIATE:
execute immediate 'alter session set current_schema=MySchema';
The past two times we have rebooted our sql server, our website has gone down. The reason appears to be because the tempdb is getting recreated and the ASPState user is losing permission to read/write to the tempdb (it is an ASP site and session data is stored in the sql server)
This was not a problem until about two weeks ago. Does anyone know how I can prevent the sql server from resetting tempdb permissions after a reboot? Or why this only started happening recently? We are using MS SQL Server 2005.
First off, you shouldn't assign permissions to the tempdb directly. For the obvious reasons that it gets recreated on every reboot.
Which actually raises a question: why do you need to have direct permissions to this database anyway?
You don't need any permissions beyond just being able to connect to sql server in order to create temp tables. However, if you are creating real tables in the tempdb, then I highly suggest you change this to use a dedicated database for this purpose.
UPDATE
Based on Martin's comment all I can say is wow. I would never even have considered that this would have been an option.
Okay, now that I've recovered from the shock.
Create a new job in sql server that executes on a schedule. The schedule should be set to "Start Automatically whenever SQL Server Agent Starts". The job should recreate your necessary tempdb permissions.
In a nutshell, when the server is rebooted the SQL Server Agent will be restarted (provided the service is set that way). When it restarts it will kick off this job that will then fix your permissions. I'd expect the site to remain down for only a few seconds more than it takes for SQL server to completely restart.
I know this is an old question but found some new information regarding the tempdb behaviour on restarting.
The tempdb is essentially recreated from the 'model' db and that is the reason why all changes to it are lost. If you make a change to persist your changes even after restart make the same changes to the 'model' db as you would to the 'tempdb'.
Have a look at the following: Does tempdb Get Recreated From model at Startup?
The Model database is used as a template for TempDB. Add users and permissions to model and the same usere and permissions will be used on TempDB. I do not say that this is the optimal solution for every case but it worked for me in a situation where an application needed speciffic TempDB access.
Create a startup script on sql Server as below:
use master
go
drop proc AddAppTempDBOwner
go
create proc AddAppTempDBOwner as
declare #sql varchar(200)
select #sql = 'use tempdb' + char(13)
+ 'exec sp_addrolemember ''db_owner'', ''app'''
exec (#sql)
go
exec sp_procoption 'AddAppTempDBOwner', 'startup', 'true'
go
Here's a script to create a startup stored procedure, which loops over Logins and creates Users in tempdb as db_owner. This script does not have harcoded logins.
As a result even after SQL machine restarts all SQL logins will have privileges to access tempdb.
USE [master]
GO
IF EXISTS ( SELECT *
FROM sysobjects
WHERE id = object_id(N'AddUsersToTempDb')
and OBJECTPROPERTY(id, N'IsProcedure') = 1 )
BEGIN
DROP PROCEDURE AddUsersToTempDb
END
GO
CREATE PROCEDURE AddUsersToTempDb
AS
DECLARE #loginname as NVARCHAR(100);
DECLARE Login_Cursor CURSOR FOR
SELECT loginname
FROM master..syslogins
OPEN Login_Cursor;
FETCH NEXT FROM Login_Cursor INTO #loginname;
WHILE ##FETCH_STATUS = 0
BEGIN
IF (#loginname <> 'sa' AND (NOT #loginname LIKE '##%') AND (NOT #loginname LIKE '%\%'))
BEGIN
PRINT #loginname
IF EXISTS(SELECT * FROM [tempdb].sys.database_principals WHERE type_desc = 'SQL_USER' AND name = #loginname)
PRINT ' - user already exists'
ELSE
BEGIN
PRINT ' - creating user'
DECLARE #Sql VARCHAR(MAX)
SET #Sql =
'USE Tempdb' + char(13) +
'CREATE USER ' + #loginname + ' FOR LOGIN ' + #loginname + char(13) +
'EXEC sp_addrolemember db_owner, ' + #loginname
EXEC (#Sql)
END
END
FETCH NEXT FROM Login_Cursor INTO #loginname;
END;
CLOSE Login_Cursor;
DEALLOCATE Login_Cursor;
GO
EXEC sp_procoption 'AddUsersToTempDb', 'startup', 'true'
GO
The tempdb database in SQL server is (from everything I've ever read, heard, or experienced) completely dropped and recreated every time the service is started up. Thus, anything stored within or written to that database, including roles, users, or other access right settings, will be wiped out. Barring some fussy code to set/reset them whenever the instance starts up, I don't think you can work around this. (I don't think anything set in the model database gets copied over to tempdb when it's created, but I've never even thought about that...)
Are any such settings being written to that databases? Are you sure that your system has not been recently changed or updated to do so? Possibly relevant, how often does the SQL instance get stopped and restarted? (It's not uncommon--if not wise--for SQL to run for months if not yers without a restart...)
As per this how-to, I've successfully configured IIS on my XP-SP3 dev box for SQL Server 2008 Express to save ASP.NET session state information. I'm just using SQL Server because otherwise on every recompile, I was losing the session state which was obnoxious (having to re-login). But, I'm facing an annoying issue in that every time I restart SQL there's this error, and sometimes one or two other very similar friends:
The SELECT permission was denied on the object 'ASPStateTempSessions',
database 'tempdb', schema 'dbo'.
To fix the error, I just open Management Studio and edit the User Mapping for the login/dbo I'm using on the ASPState db, and re-add tempdb to that user with all but deny permissions. Apparently, once the right permissions are there, ASP.NET is able to automatically create the tables it uses. It just can't run that CreateTempTables sproc until the right security is there.
THE QUESTION...
Is there a way to not have to re-do this on every restart of the SQL Server?
I don't really care right now about keeping the temp data across restarts, but I would like to not have to go through this manual step just to get my web app working on localhost, which uses session state variables throughout. I suppose one could resort to some kind of stored procedure within SQL Server to accomplish the task for this machine when the service starts, to not have to do it manually. I'd accept such an answer as a quick fix. But, I'm also assuming there's a better recommended configuration or something. Not seeing an answer to this on the how-to guide or elsewhere here on StackOverflow.
Both answers seem valid; but with most things Microsoft, its all in the setup...
First uninstall the ASPState database by using the command:
aspnet_regsql –ssremove –E -S .
Note:
-E is to indicate you want to use integrated security connection.
-S informs what SQL server and SQL instance to use, and the "." (dot) specifies default local instance
Then re-install using the command:
aspnet_regsql –ssadd –sstype p –E -S .
Note:
The sstype has three options, t | p | c ... the first "t", tells the installer to host all stored procedures in the ASPState database, and all data in the tempdb. The second option "p" tells the installer to persist data to the ASPState database. The last option "c" allows you to specify a different 'custom' database to persist the session state data.
If you reinstall using the "-sstype p" you then need only to supply datareader/datawriter to the ASPState database for the user that's making the connection (in most cases, the application pool's identity in IIS).
The added benefit of persisting the data is that session state is retained even after a restart of the service. The only drawback is that you need to ensure the agent cleanup job is pruning old sessions regularly (it does this by default, every minute).
Important:
If you are running a cluster, you must persist session data. You're only option is to use sstype 'p' or 'c'.
Hope this sheds light on the issue!
For the record, I did find a way to do this.
The issue is that the tempdb is recreated from the model db each time the service restarts. The gist of the solution is to create a stored procedure that does the job, and then make that procedure run at startup.
Source code (credit to the link above) is as follows:
use master
go
-- remove an old version
drop proc AddAppTempDBOwner
go
-- the sp
create proc AddAppTempDBOwner as
declare #sql varchar(200)
select #sql = 'use tempdb' + char(13) + 'exec sp_addrolemember ''db_owner'', ''app'''
exec (#sql)
go
-- add it to the startup
exec sp_procoption 'AddAppTempDBOwner', 'startup', 'true'
go
Well done for finding the strangest way possible to do this.
The correct answer is as follows:
use master
go
EXEC sp_configure 'Cross DB Ownership Chaining', '1'
go
RECONFIGURE
go
EXEC sp_dboption 'ASPState', 'db chaining', 'true'
go