SQL 2012 :: AlwaysOn Secondary Node Slower Than Primary
Oct 3, 2014
I have a SP that runs on the primary in 18 min and 45 min on the secondary( poorly written cursor,trying to fix it).Both machines are Exactly the same.I ran them in the middle of the night when no one was on the Sec. Node as we use it for reporting.
PLE: 7,000+
AVG Disk sec/write below .01
AVG Disk sec/read below .01
CPU below 5%
both machines set a max dop 4
I have not used log shipping before and find myself in a position where I need to reboot the secondary node and then the primary node and I don't actually need to failover.
Is there anything I need to be aware of. When rebooting the secondary node I assume the transactions will be held in the primary nodes log till the secondary comes back and just carry on once back up?
When rebooting the primary node nothing needs to be done and the log shipping will just start again once it has come back?
I was working on a job to send me info each morning about database file free space and was noticing some odd things when looking at the log file VLFs for one of my databases in an AlwaysOn availability group.When I run DBCC LOGINFO on the secondary replica for this database, I get what I expect and most VLFs have a status of 0 (indicating the VLFs are reusable or unused). When I run DBCC LOGINFO on the primary replica, all of the VLFs have a status of 2 (active or recoverable).
Since log backups on the secondary replica in AlwaysOn still truncate the log in the primary replica, I would expect that the VLFs in the primary replica would also be mostly in a reusable or unused state. My log file sizes are the same size on each server and my backups are completing successfully. what might be causing the VLFs on the primary replica to have a status of 2 in DBCC LOGINFO when taking log backups from the secondary replica?
I have set up a 2 node availability group to take advantage of using the secondary node for a read-only replica. I actually am having two issues. The first being I can connect to the primary node using the listener dns name and ip address, but no longer can connect via its actual host name or ip address. I can ping the address with no problem, but I can't connect to port 1433 using the actual host name or ip address.
I am no problem connecting to the secondary node using its host name, but can not get to it through the listener using the applicationintent=readonly. Eventually I would like for everything to connect through the listener name, but for now still need to connect via the server's host name and don't understand why; everything I read is that the primary node should be able to be connected via both the host name and the listener name.
In always on under availability group server name properties can see the option Readable Secondary. In that for secondary server the Readable Secondary Option is YES and for Primary it is Read-Intent. I believe Read-Intent allows only read only connections and YES allows all user connections.
In always on under availability group server name properties can see the option Readable Secondary. In that for secondary server the Readable Secondary Option is YES and for Primary it is Read-Intent. I believe Read-Intent allows only read only connections and YES allows all user connections.
What exactly it means for the primary and secondary?
I have an AlwaysOn Availability group configured between 2 nodes (Synchronous)
Automatic failover was working fine until recently
I can failover between the nodes manually but automatic failover doesn't seem to be working. In my earlier test, I would shut down the SQL Service on the primary and within seconds, the secondary replica would take over. Recently I have performed the same test and the secondary replica enters the resolving state and the DB in unavailable.
I have tried everything here: [URL] ....
The only change I made was changing the availability mode from Synchronous to Asynchronous - Could that be the cause?
Secondary replica database(setup in async mode) of AlwaysON went in "restricted mode" during weekly reindex operation.
So I have tried below steps
1) Executed following statement on the same secondary replica database where the issue exists
alter database <DBNAME> set multi_user with rollback immediate
but it failed with the error saying "The operation cannot be performed on database "dbname" 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. ALTER DATABASE statement failed."
2) Primary database is multi_user but still tried following command on primary replia database(thinking it will replicate)
alter database <DBNAME> set multi_user
but no luck. The secondary alwaysON database shows (synchronizing) as the alwaysON is set in async mode but the command doesn't replicate across secondary
so we are left with the only option to re-setup alwaysON but I want to avoid it as database size is huge..
What happens when an automatic failover occurs, in a two server AlwaysOn Availability Group configuration, where the secondary replica is configured as read-only?
Will it only allow read-only connections, or will it become read-write and can accept INSERT, UPDATES and DELETES when assigned the new role as Primary?
Is it correct that adding a third server/node, that just acts as passive and should be used for automatic failover, to support true HADR, would NOT need another license .. and that licenses would only be required for the previous Primary and Secondary (Read-Only) replicas?
Our network guys have to carry out an IBM Flex Chassis move at our data centre, which will affect the primary replica of one of our SQL 2012 AlwaysOn Availability Group nodes (the secondary replica won't be affected).
They have suggested using vMotion to migrate the primary replica to another virtual host, which will result in a very brief period of network outage for the node.
I've done some reading and have seen a few potential issues regarding Stun During Page Send (SDPS) and increasing thresholds within WSFC. Unfortunately, we're not able to test this prior to the migration, so I have a few questions...
Would it be necessary to failover to the secondary replica node before performing the vMotion (and back again afterwards)?
I know now that AlwaysOn feature HAS to be installed/configured on a Windows Clustering environment, BUT the secondary replicas, like the Disaster recovery replica residing in a different Data Center HAS to be also in a Windows Clustering environment or can it reside on a SINGLE SQL Server INSTANCE?.
I have created a Test SSIS Package within BIDS (VS 2K8, v 9.0.30729.4462 QFE; .NET v 3.5 SP1) that connects to our Test Listener.
There is only 1 Connection Manager Object, and OLE DB Provider for SQL Server.
The ConnectionString lists: Provider=SQLOLEDB.1;Integrated Security=SSPI
The Test Connection within BIDS works.
The Package Control Flow has just 1 Object, and Execute SQL Task that performs an Exec on an SP that contains only a Select (Read).
The Package runs within BIDS.
I've placed this Package within a Job on the Primary Node. Ive run the job successfully using 32 bit runtime on and off. The location of the file on the server happens to be on a share that resides on what is currently the Secondary Node.
When I try to run the exact copy of this Job on the Secondary Node (Which has been Set up for Read All Connections; Yes), I get an error, regardless of the 32 bit runtime opiton. At this point, the location of the file is on the Secondary Node.
The Error is: "Login failed for user 'OurDomainAgent_Account'".
The Agent is a member of NT ServiceSQLServerAgent on both instances, and that account is a member of SysAdmin. Adding the Agent account as well, and giving that account SysAdmin, makes no difference either.
We are rolling out the use of Availability Group listeners to our SQL Server 2012 Environment which has a 2 node multi-subnet cluster. The Primary is R/W and the Secondary is a non-readable node that would be manually failed over to in a DR scenario
I have set up the AGL and asked the sysadmins to create a DNS record in both subnets with fixed IP's.
The issue I have having is that when I ask the app developers to connect to the databases using the AGL it is totally random whether the AGL resolves to the Primary or DR node - as a result that are having problems getting their apps to connect.
I was thinking of asking the sys admins to remove the DNS record in the DR subnet and then add it back in should we need to fail over - but I was thinking there must be a better way.
"If we fail over a SQL AG group on a failover cluster from one node to another making the secondary the new primary, is there any reason why we would have to fail it back over to the old primary node?"
In my environment always on is there. Today I observed that primary server fail over to secondary server .now the secondary server acting as primary role.
Can I know when is fail over is happened and who did the fail over. Is there any script to find this?
During the installation of the SSISDB in SQL 2012 AG, the password used to encrypt the database was not preserved. Now when the server is failed over, the SSISDB on the new primary node is not use-able.Document the password and decrypt after using the master key after failover.
In always on docs in msdn they mention only about backup of secondary.. explain the backup of primary or how logs are managed in primary database. My doubt is a normal database in full recovery mode the log file will grow if we didnt take proper log backup,how the same is managed in primary in Always On.
y'day we faced situation one of the primary server went down and unable to failover the services to second node . by checking in logs we found
Cluster network 'Public' is partitioned. Some attached failover cluster nodes cannot communicate with each other over the network. The failover cluster was not able to determine the location of the failure. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Secondary server is offline due to a hardware issue and the log files are growing on Primary sever for availability databases. The log drive is running out of space. How can I stop the log growth for the primary databases?
I have a scenario where a customer is going to be using Log Shipping to the DR site; however, we need to maintain the normal backup strategy on the current system. (i.e. Nightly Full, Every 6 Hour Differential and Hourly Transaction Log backup)I know how to setup Transaction Log Shipping and Fail-over to DR and backup but now the local backup strategy is going to be an issue. I use the [URL] .... maintenance solution currently.
Is it even possible to do regular backups locally keeping data integrity for your backup strategy with Transaction Log Shipping enabled?
I have 2 SQL Server replicas configured on SQL Server 2012 AlwaysOn. e.g. SQL1 & SQL2.
I have configured backup job on both SQL Server with the following statement. and the job occurs every 10 minutes.
•declare @DBNAME sysname,@sqlstr varchar(500) set @DBNAME = 'dba' IF (sys.fn_hadr_backup_is_preferred_replica(@DBNAME)=0) BEGIN --Select 'This is not the preferred replica, exiting with success';
[Code] ...
I turned off SQL2 for Windows maintenance. So there is only SQL1 is online. Afterwards. I checked the backup folder and didn't see any new backup files was created after SQL2 was offline. I rerun the job. It still doesn't backup database on the Primary Replica. Then I searched on SQL Server Book online. It says
Prefer Secondary
Specifies that backups should occur on a secondary replica except when the primary replica is the only replica online. In that case, the backup should occur on the primary replica. This is the default option.
According to what it says, it should backup on the Primary Replica.
i have created a new login in primary server and provided dbowner permission to primary db.how do i transfer this login to secondary server and assign the same permission to secondary db ?
Currently in my environment we are using SQL server 2012.We setup Alwayson with synchronous commit.Details of existing AlwaysOn: one primary and two secondary.
Primary: On-Premise server. Secondary1: On-Premise server. Secondary2: Azure VM. Requirement: We need to add Secondary3 New Azure VM on same AG with asynchronous mode or synchronous mode. Or We need to create one more AG on same DB and add the new replica with asynchronous.Is it possible above 2 option in this scenario? My cluster environment is Manual failover only not auto failover.
We had a big issue today during maintenance work in our SQL environment.
So our environment: - 2x SQL Server 2014 Enterprise on Windows Server 2012 R2 (SRV1 and SRV2) -- Both Hyper-V VMs on different Hosts -- Both configured to an Windows Failover Cluster and AlwaysOn Availability Group (AG1) -- AG Listener: AG1_lis -- No shared storage (each Hyper-V Host has its own local storage) -- Asynchronous Mode -- SRV1 is primary, SRV2 is secondary SQL node
What happened? - Shutting down Windows on SRV2 due hardware maintenance - Cluster goes offline, AG1 goes offline -- Error message: "Stopped listening on virtual network name 'AG1_lis'." -- Error message: "The availability group database "DatabaseXY" is changing roles from "PRIMARY" to "RESOLVING" because the mirroring session or availability group failed over due to role synchronization."
Results? - AG1_lis wasn't available for our applications and they stopped working properly because database connection was lost!
I think, I HOPE, this is not the normale behaviour when one node is shutting down (especially the secondary node!)
I noticed that after a SQL AlwaysOn failover, one of the DB in the secondary replica is stuck in Restoring state. The primary replica shows that it is in a synchronized state. These are the error logs from SSMS. How do I trace the cause of the problem?
Error: 5901, Severity: 16, State: 1. Nonqualified transactions are being rolled back in database for an AlwaysOn Availability Groups state change. Estimated rollback completion: 0%. This is an informational message only. No user action is required Error: 18400, Severity: 16, State: 1.
One or more recovery units belonging to database failed to generate a checkpoint. This is typically caused by lack of system resources such as disk or memory, or in some cases due to database corruption. Examine previous entries in the error log for more detailed information on this failure.
The background checkpoint thread has encountered an unrecoverable error. The checkpoint process is terminating so that the thread can clean up its resources. This is an informational message only. No user action is required.
I recently configured SQL Server 2012 AlwaysOn Availability group using two nodes - a primary and one secondary read only replica. The group is residing on a windows 2012 cluster with an smb file share as the quorum. I am able to successfully failover through SQL and through the windows 2012 cluster. When I look at the group dashboard on the primary server and view the Operational state of each node I notice an odd value. The secondary role server is listed as Unknown. I also noticed that the Availability replicas node icons in object explorer are displaying the same icon on the primary server but on the secondary server, the primary server is shown as a server with a question mark.
Am I missing a permissions setting or is this normal behavior.
For example:
ServerA is the primary ServerB is the secondary ServerA lists the servers in Object Explorer as:
ServerA (Primary)ServerB (Secondary) ServerB lists the servers in Object Explorer as:
ServerA ServerB (Secondary)
The primary is never listed a primary on the secondary server. Again failovers are working properly, but I want to be sure I am not missing a setting somewhere.
I have a two node HA Always on group using a Listener. I would like to force a certain AD group to always be forced to the secondry node as they would only ever need to run select statements. If there an easy way to do this without using logon triggers?