为什么我的 tempdb 在服务器重新启动时会重置权限?

发布于 2024-10-21 23:49:47 字数 233 浏览 7 评论 0原文

过去两次我们重新启动 SQL Server,我们的网站就瘫痪了。原因似乎是因为 tempdb 正在重新创建,并且 ASPState 用户失去了读/写 tempdb 的权限(它是一个 ASP 站点,会话数据存储在 sql server 中),

直到大约两周后这才成为问题前。有谁知道如何防止 sql server 在重新启动后重置 tempdb 权限?或者为什么这种情况最近才开始发生?我们使用的是 MS SQL Server 2005。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

风和你 2024-10-28 23:49:47

首先,您不应该直接向 tempdb 分配权限。由于显而易见的原因,它会在每次重新启动时重新创建。

这实际上提出了一个问题:为什么您需要拥有此数据库的直接权限?

除了能够连接到 sql server 来创建临时表之外,您不需要任何权限。但是,如果您在 tempdb 中创建真实的表,那么我强烈建议您更改此设置以使用专用数据库来实现此目的。

更新
根据马丁的评论,我只能说哇。我从来没有想过这会是一个选择。

好吧,现在我已经从震惊中恢复过来了。

在 sql server 中创建一个按计划执行的新作业。计划应设置为“每当 SQL Server 代理启动时自动启动”。该作业应重新创建必要的 tempdb 权限。

简而言之,当服务器重新启动时,SQL Server 代理将重新启动(前提是服务是这样设置的)。当它重新启动时,它将启动此作业,然后修复您的权限。我预计该站点将仅比 SQL Server 完全重新启动所需的时间多几秒钟。

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.

意中人 2024-10-28 23:49:47

我知道这是一个老问题,但发现了一些有关重新启动时 tempdb 行为的新信息。
tempdb 本质上是从“model”数据库重新创建的,这就是对它的所有更改都会丢失的原因。如果您进行更改以在重新启动后保留更改,请对“model”数据库进行与“tempdb”相同的更改。
看一下以下内容: tempdb 是否在启动时从模型重新创建?

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?

陌路终见情 2024-10-28 23:49:47

Model 数据库用作 TempDB 的模板。将用户和权限添加到模型中,并且将在 TempDB 上使用相同的用户和权限。我并不是说这对于每种情况都是最佳解决方案,但它在应用程序需要特定 TempDB 访问的情况下对我有用。

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.

半仙 2024-10-28 23:49:47

在sql Server上创建启动脚本如下:

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 

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 
旧街凉风 2024-10-28 23:49:47

下面是一个用于创建启动存储过程的脚本,该过程循环登录并在 tempdb 中以 db_owner 身份创建用户。该脚本没有硬编码登录。

因此,即使在 SQL 计算机重新启动后,所有 SQL 登录名也将具有访问 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

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
风吹雪碎 2024-10-28 23:49:47

每次服务启动时,SQL Server 中的 tempdb 数据库(根据我读过、听到过或经历过的所有内容)都会完全删除并重新创建。因此,存储在该数据库中或写入该数据库的任何内容(包括角色、用户或其他访问权限设置)都将被清除。除非在实例启动时使用一些繁琐的代码来设置/重置它们,否则我认为您无法解决此问题。 (我不认为模型数据库中设置的任何内容在创建时都会复制到 tempdb,但我从未想过这一点...)

是否有任何此类设置被写入该数据库?您确定您的系统最近没有进行过更改或更新吗?可能相关的是,SQL 实例多久停止并重新启动一次? (SQL 运行数月甚至数年而不重新启动的情况并不罕见……)

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...)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文