Making SQL sense

+44 (0)20 3051 3595 info@coeo.com
coeoClose

Making SQL sense

+44 (0)20 3051 3595 info@coeo.com

Careers

We're looking for people who share our commitment to excellence in Microsoft's data platform to join us consultants working on exciting business intelligence, analytics, and SQL Server projects on-premises and in the cloud.

Preparing your data platform for peak period sales

The Coeo Blog

 

retail blog header.jpgIn the last few years, Black Friday and Cyber Monday have become synonymous with both getting a good bargain and causing retail pandemonium. However, times are changing. News items about people queueing outside shops 4am have been replaced with those about just how much consumer spending has moved online. Quite some achievement for a couple of days still relatively new to the British retail calendar.

For the retailers that Coeo works with, November is the new December. Peak period for them now comes in late autumn rather than in deep mid-winter, meaning their planning starts in late-June rather than early-autumn. But how do Coeo’s customers prepare?

Preparing for Peak

Everyone plans to proactively maintain their data platform but the reality for some organisations is often that “if it ain’t broke, don’t touch it”. We all know that tinkering can be bad, but we all also know that proactive maintenance is good, often essential. The following list is some of the most essential preparation that Coeo recommends retailers perform as they prepare for their peak period:

  • Testing high availability – Although it’s often confused with a complete disaster recovery test, it’s just as important to know that a regular failover cluster or Availability Group failover from an active to an inactive node works as expected. In stable production environments, it’s possible for database servers not to be failed over for several months - increasing the chances of resources being missing after the failover. Although it’s not necessary to do it too often, manually failing over a production workload during a period of planned downtime helps check that the storage, networking, logins, and scheduled tasks the database server needs are still available.
  • Testing data quality – Knowing that the data in reports is accurate is always important but finding out it’s wrong during peak period is probably the worst possible situation. It’s crucial then to test the quality of the data that reports - whether existing or ad-hoc – provide well in advance. Do the totals they provide match what would be calculated manually? Is all the expected data appearing on reports? If reports are only run once a quarter or even once a year, then it’s common to find changes in source data not being reflected in reports – and data being missed.
  • Checking network stability – Peak period can see the amount of network traffic a database server handles increase significantly, often caused by more application traffic or users running larger ad-hoc reports. These bulkier workloads can amplify the effect of unreliable network connectivity between database servers, application servers, and end users – often seen as disconnected sessions or connections timing out. A check of network card statistics for dropped packets and connectivity errors, along with scans of error logs for network warnings can help find any significant issues.
  • Server patching – While everyone knows that patching services is important, it’s typically one of the most delayed pieces of proactive maintenance. A large backlog of outstanding patches not only means more downtime to apply them, but more time to first test them. If that’s the situation your database server is in, then it’s probably worth scheduling several downtime windows rather than one large one to patch Windows and SQL Server separately. It’s also important to schedule this for as soon as possible in case of any incompatibilities or error messages which need to be investigated. Finally, it’s also good practice to patch inactive failover cluster nodes first, and then patch the active nodes several days later.
  • Baselining performance – Knowing how hard a server is working is important, but not as important as knowing how effective it’s being by relating server performance statistics to business productivity metrics. If a database server is running at 80% utilisation, but supporting 1,200 POS transactions a minute then that might be nothing to worry about. Whereas 80% utilisation for only 12 transactions a minute may well be the sign of a serious bottleneck.

 

How Coeo helps customers prepare for peak

If you need assistance with any of your preparations for your peak period, then Coeo can help you by delivering retail data and analytics solutions delivered by our experienced SQL Server consultants:

  • Data platform healthchecks – validating that your transactional SQL Server database servers are configured to provide the highest levels of availability, performance, and security.
  • Dedicated support – providing 24x7 specialist remote DBA support to supplement the operational support that internal technical teams provide.Read why smart fashion retailers are betting the future of their business on data mastery

Subscribe to Email Updates