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
Related
I need to set up Always on Support for SSISDB and I am receiving this message:
The operation cannot be performed on database "SSISDB" because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.
I Did have this set up no problem before, but we had to delete the Catalogue and recreate it. And once we have done this, it wont turn back on.
We have AG Set up for all of our other databases and trying to add SSISDB into the AG works but then says we need Always on Support turned on, and this is when we receive the error message.
The operation cannot be performed on database "SSISDB" because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.
As error suggest the cause can be mirroring session and the main database remains accessible when a mirroring session is paused or removed.
To Suspend mirroring session use following command:
ALTER DATABASE _database_name_ SET PARTNER SUSPEND
where database_name denotes the mirrored database whose active session you want to pause.
The mirror database no longer keeps up with the principal database when mirroring is pausing, which results in the principal database running exposed.
Also see, Configure Integration Services Catalog Database SSISDB by Rajendra Gupta for more information.
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.
In My University Management System i want to Perform Data Migration on Specific Day and so that i want close all open connections and Perform Data Migration as a Db admin user and after that Allow user to Establish connections to Database
after some Searching i find that script
To Disable MultiUser
alter database dbName set single_user with rollback immediate
To Enable MultiUser
alter database dbName set multi_user with rollback immediate
Question :
how to Perform my required Operation as a db admin?
it is a good way to do this or some better way ?
what does Disable Script doing?
what does Enable Script doing?
From this Disable Scriptall open connections will close ?
What you said is about the same what we do in this situation. The first statement puts the DB in "single_user" mode. That means, only YOUR current session is connected to the db after that statement. The "with rollback immidiate" option specifies that all open transaction and current queries and connections are closed and rolled back, so the database is in consistent state afterwards.
Personally, I dislike the "single_user" mode, because it allows any single user to connect if you accidentially close your connection. I'd use "restricted_user" instead. In that mode, only members of the db_owner fixed database role and dbcreator and sysadmin fixed server roles are allowed to connect to the database, but it does not limit their number. That will work better IF your users are not db_owner.
You second example just reverses that change and opens the DB to everyone ("multi_user") again.
The issue is that there are certain users that keep certain applications open instead of shutting down their PCs overnight - this keeps locks on tables and that has an impact on other systems that rely on the tables being in an 'unlocked' state to do their updates etc.
I want to kill all USER connections (only) to a database. I will need to run this as a job on a nightly basis. I don't want to use:
ALTER DATABASE xxx SET SINGLE_USER WITH ROLLBACK IMMEDIATE
As I do not want to destroy the integrity of the database transaction logging.
Any ideas as to how this may be accomplished?
Thanks in advance,
JR
I need to keep synchronized a couple of databases, one is on sql 2000 and the other on 2005. The one on 2000 should be kept in read-only mode to make sure the users does not enter data. The 2005 is the one which are going to be updated by the users.
So I could develop a script to truncate and insert into the 2000 version with data from 2005 every night. My question is if there is some way to disable the read-only mode temporaly while the script is running. Is there a better approach?
Thanks,
You can disable the read-only mode while the script is running. You may also want to set RESTRICTED_USER to keep any users from accessing the database while processing.
I would tend along the response offered by Mike Henderson.
Essentially leverage db security to prevent users from modifying data and allow the account used to synchronize data to write.
Not sure what your time constraints are, but if you are relying on the db to be read-only to prevent end-users making changes, there is the possibility that they could get in during the time period that the db is in read/write mode.
Just for future reference, this is how I proceeded,
ALTER DATABASE MyDB SET READ_WRITE WITH ROLLBACK IMMEDIATE
ALTER DATABASE MyDB SET READ_ONLY WITH ROLLBACK IMMEDIATE
Thank you,