I wrote a stored procedure in 'test' database.This procedure will create temp table to tempdb.
I found when SQL service restart.
It lost my user in tempdb and
procedure has no permission to access in.
I need to add user again in tempdb: security-> user.
User Setting:
Database-Level Roles : public & db_owner
Fixed-Database Roles : db_owner
When service restart I want my user setting keep it.
Is anything can to that?
Objects are in tempdb only persist until they are dropped or the instance is restarted. This is by design. "tempdb" means "Temporary DataBase". The objects within are inherently temporary, as the database is rebuilt each time the server restarts.
From TempDB Database:
Operations within TempDB are minimally logged so that transactions can be rolled back. TempDB is re-created every time SQL Server is started so that the system always starts with a clean copy of the database. Temporary tables and stored procedures are dropped automatically on disconnect, and no connections are active when the system is shut down. Therefore, there is never anything in TempDB to be saved from one session of SQL Server to another. Backup and restore operations are not allowed on TempDB.
If you want permanent objects, you should create them in a user database, such as your test database.
When SQL Service restarts then TempDB automatically re-created.Means Everytime it copies the structure of Model DB.If you want the user should be existed in TempDB even after restarted then you need to create the user in Model DB.But for security reasons i would suggest you to create the user in test DB only.
Related
Copying a database in the Azure Portal is never ending.
Usually, when I copy a 250GB database, it completes in just under an hour.
Today, when I copy, it never seems to finish, it has been over two to three hours now.
And in the server activity logs, the last entry just says an update occured
Any idea on how to see more progress, percent complete, or any other way to see what might be locking it? Nothing of use can be seen in the activty log json.
You can use SYS.DM_OPERATION_STATUS to track many operations including copy in SQLAZURE..
Documentation states
To use this view, you must be connected to the master database. Use the sys.dm_operation_status view in the master database of the SQL Database server to track the status of the following operations performed on a SQL Database:
Below are the operattions that can be tracked
Create database
Copy database. Database Copy creates a record in this view on both the source and target servers.
Alter database
Change the performance level of a service tier
Change the service tier of a database, such as changing from Basic to Standard.
Setting up a Geo-Replication relationship
Terminating a Geo-Replication relationship
Restore database
Delete database
You can also try sys.dm_database_copies in master database for info about copy status ..This has percent_complete field and below is what documentation has to say about this
The percentage of bytes that have been copied. Values range from 0 to 100. SQL Database may automatically recover from some errors, such as failover, and restart the database copy. In this case, percent_complete would restart from 0.
Note:
This view has info only during the duration of copy operation..
Does SQL Server recreate the primary files, secondary files for the TempDB database every time the server is restarted? Or does it just refresh the .mdf, .ndf or log files every time the server restarts?
As per msdn documentation, yes it is re-created everytime SQL Server is started:
Operations within tempdb are minimally logged. This enables transactions to be rolled back. tempdb is re-created every time SQL Server is started so that the system always starts with a clean copy of the database. Temporary tables and stored procedures are dropped automatically on disconnect, and no connections are active when the system is shut down. Therefore, there is never anything in tempdb to be saved from one session of SQL Server to another. Backup and restore operations are not allowed on tempdb.
I have SQL Server 2008 installed on my machine and also Reporting Services Configuration Manager. When I connect to SQL Server, I found two databases already there.
ReportServer
ReportServerTempDB
I know ReportServer is to store reports, data sources, snapshots, subscriptions, etc. But what is ReportServerTempDB for? Why is it created? Is that necessary (for our use)?
Read the documentaion on report server database
The databases are created together and bound by name. By default, the database names are reportserver and reportservertempdb, respectively.
Report Server Temporary Database
Each report server database uses a related temporary database to store
session and execution data, cached reports, and work tables that are
generated by the report server. Reporting Services does not re-create
the temporary database if it is missing, nor does it repair missing or
modified tables. Although the temporary database does not contain
persistent data, you should back up a copy of the database anyway so
that you can avoid having to re-create it as part of a failure
recovery operation. If you back up the temporary database and
subsequently restore it, you should delete the contents. Generally, it
is safe to delete the contents of the temporary database at any time.
However, you must restart the Report Server Windows service after you
delete the contents. If you delete the temporary database, you can
create a new database, and then run the Catalogtempdb.sql script to
add the table structure. The temporary database must have the same
root name as the primary report server database.
I need to configure merge replication between 2 databases. These databases have foreign key integrity, which makes the replication not work, so I resorted to:
Dropping all FKs on subscriber database,
Replicating, and
Recreating the FKs.
This however leaves the subscriber database vulnerable to FK violations.
So my questions are:
Does the replication lock the subscriber database, raise a transaction, and render the database unusable in any way during the process?
If not, could I initiate such a lock manually through TSQL?
If none of the above is possible, is there something I'm missing?
don't know about lock initiated by replication, but for the time of your maintenance you can set the whole database to single_user or restricted_user.
ALTER DATABASE SET RESTRICTED_USER
i recommend the second one as it allows access to the database to all users who are, quote:
members of the db_owner fixed database role and dbcreator and
sysadmin fixed server roles
(see here: http://msdn.microsoft.com/en-us/library/aa933082%28SQL.80%29.aspx)
, only regular users are restricted. it will wait until all regular user connections are done
ALTER DATABASE SET RESTRICTED_USER WITH ROLLBACK IMMEDIATE
will kill all such connections immediately. This
select DATABASEPROPERTYEX ('ocon_reportdb','UserAccess') DATABASEPROPERTYEX_UserAccess
reads the current status
UPDATE:
there are maintainance activities such as statistics performed by the database engine. using WITH ROLLBACK IMMEDIATE will also kill those connections, so be careful
UPDATE2: specs to have acces in restricted_user-mode
I have two SQL 2005 instances that reside on different networks. I need to backup a database from instance A and restore it to a database in instance B on a weekly basis so that both databases hold the same data. After the restore, logins SIDS on database B are changed and therefore users can't log into database B and connection strings for the web application it supports are broken. Is there a work around for this? Thanks.
There is a stored procedure for that: sp_change_users_login (see: http://msdn.microsoft.com/en-gb/library/ms174378.aspx). In particular, take a look at the Auto_Fix action. However, be aware that this SP is going to be deprecated in the future.
Insead, we're now supposed to use ALTER USER (see: http://msdn.microsoft.com/en-gb/library/ms176060.aspx).