It’s my passion to open mind  and continue  to learn in Technology.

Recently, I was working a stored procedure that was written in MS SQL Server 2008 R2 and migrated into MS SQL Server 2017.

It has been noticed that stored procedure execution time was increased since migrating to SQL Server 2017.

When I executed the stored procedure, it took about 2 minutes and 45 seconds.  And, The Execution Plans showed  several Remote Query.  My further research, I found this stored procedure used several linked server.

Then, switching the database compatibility mode to SQL Server 2008 (100), then re-executed the SP.

The execution time was down to 1 minutes and 35 seconds.

I did some researches and found a hint that could improve the execute time in this particular stored procedure.

The hints was :

OPTION (USE HINT ( ‘FORCE_LEGACY_CARDINALITY_ESTIMATION’ ))‌

by including this hint at the end of the SELECT statement.

Then, I re-tested this stored procedure in SQL Server 2017.  Amazingly, the execution time only tool 34 seconds.

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)

• Right click the user database
• Select Resume Data Movement

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!!!

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.

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 »

I found a solid article that discussed a common SQL wait type that provided by several SQL MVPs

https://logicalread.com/common-sql-server-wait-types/#.WiF8YnmWyUk

How to add additional article into existing Publication.

Method 1: To add an article after a publication is created

1. On the Articles page of the Publication Properties – <Publication> dialog box, clear the Show only checked objects in the list check box. This allows you to see the unpublished objects in the publication database.
2. Select the check box next to each article you want to add.
3. Click OK.

https://technet.microsoft.com/en-us/library/ms152571(v=sql.90).aspx

https://www.mssqltips.com/sqlservertip/2502/limit-snapshot-size-when-adding-new-article-to-sql-server-replication/

Method 2:  To add an article after a publication is created through Replication Transact-SQL Programming.

EXEC sp_addarticle @publication = N’RMS_Publication’,
@article = N’lwcase’, @source_owner = N’dbo’, @source_object = N’lwcase’,
@type = N’logbased’, @description  = null, @creation_script = null,
@pre_creation_cmd = N’drop’,
@identityrangemanagementoption = N’manual’, @destination_table = N’lwcase’,
@destination_owner = N’dbo’, @vertical_partition = N’false’,
@ins_cmd = N’CALL sp_MSins_dbolwcase’, @del_cmd = N’CALL sp_MSdel_dbolwcase’, @upd_cmd = N’SCALL sp_MSupd_dbolwcase’
GO

I was assigned a database replication projects to setup database replication that supported ETL projects for a Fire and Policy department.

The Source and Target database are located in the same domain.

I used my previous experiences and I know how to setup database replication. My previous working experiences were setting – up a Transactional replication to replication wind farm database.

It’s important to understand the database replication terminology terms like:

• • Publisher
    • The MS SQL Server Database instance that provided data available to Subscribers. The Articles like Tables, and Views which are to be replicated are defined at the publisher.
  • Distributor 
    • The MS SQL Server Database instance that distributes data from one or more Publisher to one or more Subscribers
  • Subscriber
    • The MS SQL Server Database that going to receive data from Publishers.
  • Pull Distribution
    • Setup and located in Subscriber MS SQL Server
  • Push Distribution
    • Setup  and located in Publisher MS SQL Server.
  • Articles
    • An article is a SQL Server object like Table, View, Function, stored procedure, etc.
  • The Snapshot Agent
    • Distributes data exactly as of a point in time.
    • Prepares snapshot files containing schema and data of publication articles
    • Stores the files in the snapshot folder
  • The Distribution Agent
    • Copies the initial snapshot files from the snapshot folder
    • Copies transactions from the distribution database to one or more subscribers.
    • https://docs.microsoft.com/en-us/sql/relational-databases/replication/configure-distribution
  • The Log Reader Agent
    • Analyzes the transaction log of the publication database
    • And looks for transaction marked for replication
    • Copies the transactions marked for replication into the distribution database
    • https://docs.microsoft.com/en-us/sql/relational-databases/replication/agents/replication-log-reader-agent

My DBA Story.

As a production DBA, I wanted to make sure all production sql servers are backup properly.

And it’s amazing to me that when I assigned to Audit production Microsoft SQL Servers environment.

And I found many production databases did not have a properly backup plans as show below:

Even the database backup is known by many. Un-fortune, one did not appreciate that how important database backups

When databases failed or disaster.

So, I started implementing the backup and recovery plan like:

• Setup and Created an operator
• Setup database mail.
• Full Back up is scheduled to run on Sunday
• Differential Backup is scheduled to run from Monday through Saturday
• Log Backup is scheduled to run a daily every hour
• Added Alerts notifications