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.
Related
I have a Azure SQL Database with Auditing turned on. I noticed that my database comes online after a pause when it shouldn't. I checked the audit logs and it shows strange entries of 'sa' login trying to do smth. Not sure what these entries mean. Is a normal activity from Azure or somebody is trying to connect to my database? I believe that there is no such user 'sa' on Azure SQL databases, or am I wrong. Attaching the screenshot of audit logs.
Additional_info column shows these values (they repeat for every event).
<action_info xmlns="http://schemas.microsoft.com/sqlserver/2008/sqlaudit_data">destroyed</action_info>
<action_info xmlns="http://schemas.microsoft.com/sqlserver/2008/sqlaudit_data">event disabled</action_info>
<action_info xmlns="http://schemas.microsoft.com/sqlserver/2008/sqlaudit_data">event enabled<startup_type>automatic</startup_type></action_info>
logs
Tried Google, found nothing.
I created azure SQL database in azure portal, and I enabled auditing server level destination as storage account.
Image for reference:
After that I enabled auditing at database level with same destination of storage account.
Image for reference:
It enabled successfully, and containers are created successfully in storage account.
Image for reference:
Audit Records:
Here is my log
In this way I am not getting any error related to sa user.
As per my knowledge sa user is the admin you created during setup of SQL Azure server
According to this
Once the azure database is in pause status, it resumes automatically in the following conditions:
Database connection
database export or copy
Viewing auditing records
Viewing or applying performance recommendation
Vulnerability assessment
Modifying or viewing data masking rules
View state for transparent data encryption
Modification for serverless configuration such as max vCores, min vCores, or auto-pause delay
May be for above reason database still remains in online when you pause it.
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..
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 4 databases mirrored using High Protection mode without witness server between two servers(principal and mirror) that are in the same domain. Manual failover worked fine for several days. But later somehow the IP of the principal server was changed in the DNS, then onwards the mirror state of these databses went to disconneted state and it remained in that state only though I did change the principal servers IP to its original in the DNS server.
Why it remained in disconnected state and how to make the mirror state as synchronized?
The IP is irelevant, unless you set the partner name using IPs (which you shouldn't). The mirror is diconnected betcause the principal cannot connetc to it. You will need to investigate why this is the case:
Validate the correctness of partner names on both sides (principal and mirror). Check sys.database_mirroring
Verify the errorlog for any connectivity related messages, on both sides
use SQL Profiler to monitor for events in the Audit Database Mirroring Login Event Class, Database Mirroring State Change Event Class and Broker:Connection Event Class, on both sides
Initiate a manual mirroring session resume: alter database <dbname> set partner resume; on principal
We have set up a logshipping scenairo on 2 Sql Server 2005 machines. The secondary database is in STANDBY mode.
We want to use this secondary server for reporting purposes, as the report viewers will query this STANDBY database according to their given execute rights. So we need multiple users on this secondary server, having different execute rights on the STANDBY database.
The problem is, after seting up log shipping, we can't grant the necessary permissions to the standby database as it is read-only.
Do you have any suggestions ?
Thanks,
Umut
For some reason, till we setup a better reporting system, we need to use the Standby server for reporting purposes.
And there is a way to create new users and give necessary sp execute rights to that user on the standby server.
The simple solution is, to create a login on the primary server and Select its SID from master table. Then with "sp_addlogin" create the same login with the same SID on the Standby database.
Then, on the primary server give required rights to the user on the database. With the restored transaction logs, the execute rights will ship to standby server. Passwords don't need to be the same on two servers, so the standby report viewer user can't access the primary server with the same credentials.
Sadly, you need to look into something other than log shipping.
Log shipping works by keeping up-to-date copies of your logs in a 'continually' restoring/recovery state on the secondary server. As such, the database there is never actually 'active' or live - as it's always just applying more and more logs and waiting for the command that will make it go active.
In other words, log shipping is ONLY for high-availability - it does NOT support duplication of your data in USABLE form.
To learn more about what purpose logging serves, check out this video:
http://www.sqlservervideos.com/video/logging-essentials/
And if you really need a secondary server for reporting purposes, then I'd suggest using something like transactional replication. (It's NOT suitable for high-availability solutions because of some of the schema changes and limitations you'd have to make... but it does work well as a way to 'publish' multiple copies of your database to different servers/locations for reporting purposes.)