Personal Notes of Edwin Eu

Archive for 2018|Yearly archive page

Availability databases in unhealthy data synchronization state

In Microsoft SQL Server on 09/05/2018 at 1:43 PM

Availability databases in unhealthy data synchronization state

The AlwaysOn user database showed not healthy data synchronization state

Database on AG group showed “Not Synchronizing”

And the warnings message “Data synchronization state of some availability database is not healthy”

 

 

 

 

 

 

 

 

In the SQL Server Management Studio for Secondary availability group replicas showed below:

 

 

 

 

 

 

 

I did some research and found MSDN article posted:

https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/data-synchronization-state-of-some-availability-database-is-not-healthy?view=sql-server-2017

  • The availability replica might be disconnected
  • The data movement might be suspended
  • The database might not be accessible
  • There might be a temporary delay issue due to network latency or the load on the primary or secondary replica

Solution

Execute the following  T-SQL statement on primary and all secondary replica for the databases that showed “Not Synchronizing” status.

ALTER DATABASE  [DB_Test] SET HADR RESUME

 

How to fix the suspended data movement in MS SQL Server 2016 AlwaysOn Availability Group (AG)

In Microsoft SQL Server on 08/15/2018 at 7:17 AM

How To fix the suspended data movement in MS SQL Server 2016 AlwaysOn Availability Group (AG)

  • Right click the user database
  • Select Resume Data Movement

How to simulate a suspended data movement in SQL Server 2016 AlwaysOn Availability Group (AG)

In Microsoft SQL Server on 08/15/2018 at 7:16 AM

How to simulate a suspended data movement in SQL Server 2016 AlwaysOn Availability Group (AG)

Select one of the user database.

  • First right clicked the user database –> under Available Database à Select Suspend Data Movement
  • Re-launch the Dashboard
  • The Dashboard should show a critical state and several warnings

 

 

 

 

 

 

Click on “Critical and Warning” hyperlink to drill down and see the detail

DBA Delivers

In Microsoft SQL Server on 03/22/2018 at 2:33 PM

DBA Delivers!!!

I was assigned to a project to help GIS Department to access a production SQL Server database.

The production database will offer real time mapping for the field engineers.

However, there was concerns of performance to business applications.

Then, I offered several solution that Microsoft SQL Server 2016 can offers like Database Replication or AlwaysOn technologies.

However, Database Replication or AlwaysOn are not options and to work around solutions:

GIS Department requested to create databases on a separate VM and refresh the database once a day.

As DBA, It’s not a best practice but I’m delivered to help GIS team and field engineers.

To accomplish these tasks, I created two SSIS packages that utilize File System Task and a SQL Agent jobs that contained 8 Steps like

Source Server: MS SQL Server 2012 that support a production business application

Target Server: MS SQL Server 2016

SQL Agent job  : _DailyRestore_GIS_DBs

Steps:

  • Step 1 – Moving File from Source to Destination folder
  • Step 2 – GIS Production DB access
  • Step 3 – Restoring GIS Production Database
  • Step 4 – Granting users access GIS Production DB
  • Step 5 – GIS Development DB access
  • Step 6 – Restoring GIS Development Database
  • Step 7 – Granting users access GIS Development DB
  • Step 8 – Deleting the old backup file from Source Folder.

 

 

 

 

 

 

Then, I tested the SQL Agent job and it ran successfully.

Setting up Microsoft SQL Server 2016 AlwaysOn

In Microsoft SQL Server on 03/05/2018 at 2:18 PM

I’m continued to learn, enhance my DBA skills and knowledge on Microsoft SQL Server AlwaysOn technology on New Windows Server 2016 and MS SQL Server 2016.

There are many  an Availability Group Architecture terms that I needed to get familiars like:

  • Availability Group –
    • AG is a container that represents a unit of fail-over
    • AG can have one or more user databases
    • When the availability  Group fails over from one replica to another replica, all the user databases will fail over.
  • Primary Replica
    • Microsoft SQL Server instance that is currently hosting the AG (Availability Group).
    • The AG is active and hosting a user database that can be modified.
    • There is only one primary instance at any give point in time.
  • Secondary Replica
    • SQL Server 2012 supports four secondary replicas
    • SQL Server 2014- 2016 supports eight secondary replicas
    • is hosting a copy user database that cannot be modified.
  • Failover partner
    • SQL Server 2012 – 2014 support one failover partner
    • SQL Server 2016 – support two failover partners
    • Is the secondary replica that configured to be auto failover destination when the Primary Replica goes wrong.
  • Synchronous vs Asynchronous
    • Synchronous is designed to setup Microsoft SQL Server AlwaysOn on Premises
    • Asynchronous is designed to setup Microsoft SQL Serer AlwaysOn  outside Premises.

And, I used VMWare technology  to setup my environments.    First, I’m going to preparing three (3) Virtual Machine in VMWare

    • Computer Name: INDSQLP1N1
      • Processor: Intel @R Core (TM) i7-6700 HQ CPU @2.6GHz
      • Memory: 8 GB
      • O/S: Window Server 2016
      • Installed Microsoft SQL Server 2016 SP1
    • Computer Name: INDSQLP2N2
      • Processor: Intel @R Core (TM) i7-6700 HQ CPU @2.6GHz
      • Memory: 8 GB
      • O/S: Window Server 2016
      • Installed Microsoft SQL Server 2016 SP1
    • Computer Name: INDSQLP3N
      • Processor: Intel @R Core (TM) i7-6700 HQ CPU @2.6GHz
      • Memory: 8 GB
      • O/S: Window Server 2016
      • Installed Microsoft SQL Server 2016 Sp1
  • Second, Installed and setup Window Server 2016 Standard edition on each VM.
  • Third, I joined the Virtual Machine into my Domain Controller.
  • Forth, I am going to configure Window Server Failover Clustering with Node majority.
    • There are no share disk storage
  • Forth, I installed and setup Microsoft SQL Server 2016 SP1 on each Virtual Machine.
  • Next, I turned on the AlwaysOn High Availability features.
  • And, make sure the user database must be using full recovery mode.
  • A full database backup must have been performed.
  • Finally,  I  started setting up and configure the new Availability Group that called “365_AvailabilityGroup”


 

 

 

 

 

 


 

 

 

 

 

 


 

 

 

 

 

Read the rest of this entry »