GBG undertakes security patching each month to remain up to date and compliant. In order to ensure that this does not normally affect our customers the implementation process moves our customers’ transactional traffic around the Production platform to the resilience capacity available.

On the 23rd the Secondary SQL Server had been patched and rebooted and was observed to be using all the read capacity of it’s connected drives.  This was unusual and flagged an investigation and log review. At 16:09 the log drive connected to the SQL Server began to experience the same ‘high volume of read’ – this effectively prevented our SQL Database from processing any transactions. While this impact was only occurring on the secondary SQL server it meant that any transactions attempting to be committed to the database were blocked, thereby affecting our primary SQL Server.

GBG implements its security patching through stages of its production systems – through our development, non-production, Disaster Recovery and then Production sites – with validation and delays between each stage. This problem was not seen in other environments.

GBG has raised a problem case with our Cloud provider to support explaining this unusual behaviour. We are working with them to understand if there is an environmental or patch related issue.