SQL Server 2022 UTF-8 Support Enhancements in Collation

In SQL Server 2022, UTF-8 support has been enhanced, offering more efficient storage and better performance for text data. This blog will explore these enhancements using the JBDB database and provide a detailed business use case to illustrate the benefits of adopting UTF-8 collation.

🌍Business Use Case: International E-commerce Platform 🌍

Imagine an international e-commerce platform that serves customers worldwide, offering products in multiple languages. The database needs to handle diverse character sets efficiently, from English to Japanese, Arabic, and more. Previously, using Unicode (UTF-16) required more storage space, leading to increased costs and slower performance. With SQL Server 2022’s improved UTF-8 support, the platform can now store multilingual text data more compactly, reducing storage costs and enhancing query performance.

UTF-8 Support in SQL Server 2022

SQL Server 2019 introduced UTF-8 as a new encoding option, allowing for more efficient storage of character data. SQL Server 2022 builds on this foundation by enhancing collation support, making it easier to work with UTF-8 encoded data. Let’s explore these enhancements using the JBDB database.

Setting Up the JBDB Database

First, we’ll set up the JBDB database and create a table to store product information in multiple languages.

CREATE DATABASE JBDB;
GO

USE JBDB;
GO

CREATE TABLE Products (
    ProductID INT PRIMARY KEY,
    ProductName NVARCHAR(100),
    ProductDescription NVARCHAR(1000),
    ProductDescription_UTF8 VARCHAR(1000) COLLATE Latin1_General_100_BIN2_UTF8
);
GO

In this example, ProductDescription uses the traditional NVARCHAR data type with UTF-16 encoding, while ProductDescription_UTF8 uses VARCHAR with the Latin1_General_100_BIN2_UTF8 collation for UTF-8 encoding.

Inserting Data with UTF-8 Collation 🚀

Let’s insert some sample data into the Products table, showcasing different languages.

INSERT INTO Products (ProductID, ProductName, ProductDescription, ProductDescription_UTF8)
VALUES
(1, 'Laptop', N'高性能ノートパソコン', '高性能ノートパソコン'), -- Japanese
(2, 'Smartphone', N'الهاتف الذكي الأكثر تقدمًا', 'الهاتف الذكي الأكثر تقدمًا'), -- Arabic
(3, 'Tablet', N'Nueva tableta con características avanzadas', 'Nueva tableta con características avanzadas'); -- Spanish
GO

Here, we use N'...' to denote Unicode literals for the NVARCHAR column and regular string literals for the VARCHAR column with UTF-8 encoding.

Querying and Comparing Storage Size 📊

To see the benefits of UTF-8 encoding, we’ll compare the storage size of the ProductDescription and ProductDescription_UTF8 columns.

SELECT
    ProductID,
    DATALENGTH(ProductDescription) AS UnicodeStorage,
    DATALENGTH(ProductDescription_UTF8) AS UTF8Storage
FROM Products;
GO

This query returns the number of bytes used to store each product description, illustrating the storage savings with UTF-8.

Working with UTF-8 Data 🔍

Let’s perform some queries and operations on the UTF-8 encoded data.

Searching for Products in Japanese:

SELECT ProductID, ProductName, ProductDescription_UTF8
FROM Products
WHERE ProductDescription_UTF8 LIKE '%ノートパソコン%';
GO

Updating UTF-8 Data:

UPDATE Products
SET ProductDescription_UTF8 = '高性能なノートパソコン'
WHERE ProductID = 1;
GO

Ordering Data with UTF-8 Collation:

SELECT ProductID, ProductName, ProductDescription_UTF8
FROM Products
ORDER BY ProductDescription_UTF8 COLLATE Latin1_General_100_BIN2_UTF8;
GO

Advantages of UTF-8 in SQL Server 2022 🏆

  1. Reduced Storage Costs: UTF-8 encoding is more space-efficient than UTF-16, especially for languages using the Latin alphabet.
  2. Improved Performance: Smaller data size leads to faster reads and writes, enhancing overall performance.
  3. Enhanced Compatibility: UTF-8 is a widely-used encoding standard, making it easier to integrate with other systems and technologies.

Conclusion ✨

SQL Server 2022’s enhanced UTF-8 support in collation offers significant advantages for businesses dealing with multilingual data. By leveraging these enhancements, the international e-commerce platform in our use case can optimize storage, improve performance, and provide a seamless user experience across diverse languages.

Whether you’re dealing with global customer data or localized content, adopting UTF-8 collation in SQL Server 2022 can be a game-changer for your database management strategy.

For more tutorials and tips on SQL Server, including performance tuning and database management, be sure to check out our JBSWiki YouTube channel.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

SQL Server Always On Series: Availability group DDL operations are permitted only when you are using the master database


Introduction

During a recent attempt to perform a manual failover from Always On Availability Group from JBSAG1 to JBSAG2 using Microsoft SQL Server Management Studio (SSMS), an unexpected error disrupted the process. The error, specifically identified as Microsoft SQL Server Error 35208, posed a challenge to the manual failover operation. In this detailed account, we’ll explore the encountered issue, outline the steps taken to address it, and ultimately achieve a successful manual failover.

Issue
Upon initiating the Always On Availability Group manual failover, the process encountered a hurdle with the following error:

TITLE: Microsoft SQL Server Management Studio
Manual Failover failed (Microsoft.SqlServer.Management.HadrTasks)

ADDITIONAL INFORMATION:
Failed to perform a manual failover of the availability group ‘JBSWiki’ to server instance ‘JBSAG2’. (Microsoft.SqlServer.Management.HadrModel)

For help, click: https://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=16.100.47021.0&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&LinkId=20476

An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)

Availability group DDL operations are permitted only when you are using the master database. Run the ‘USE master’ statement, and retry your availability group DDL statement. (Microsoft SQL Server, Error: 35208)
For help, click: https://docs.microsoft.com/sql/relational-databases/errors-events/mssqlserver-35208-database-engine-error

Navigating through this error was the initial challenge, particularly when attempting the failover using the SSMS graphical user interface (GUI). Executing the ‘USE master’ statement in this context presented uncertainties, prompting a reevaluation of the failover approach.

Solution
To address the dilemma, the following steps were taken:

GUI Failover Attempt:

  • Initially, the failover was attempted through the SSMS GUI, raising questions about how to execute the ‘USE master’ statement within the graphical interface.

Scripted Failover Action:

  • The failover wizard was restarted, and instead of concluding the process through the GUI, the failover action was scripted for manual execution. I started the failover wizard again and this time instead of clicking finish at the end, tried scripting the failover action.

Manual Execution of Failover Command:

  • The failover command was manually executed from the SSMS SQLCMD query window, successfully completing the failover process.

Database Context Discovery:

  • Investigation revealed that the database context for a new query window was set to a user database (JBDB) instead of ‘master,’ leading to a pivotal realization. I tried clicking on a new query window and I saw that the database context for that query window was set to an user database JBDB and not master.

Connection Options Adjustment:

  • This is when I realized that I might have connected to the SQL Server instance with an User Database specified on the “Connect to database” in “Options <<” as part of making a connection from SSMS. Please check screenshot below,

After realizing this, I disconnected the existing sessions on SSMS and changed “Connect to database” in “Options <<” to “Master” and connected to SQL server JBSAG1 and JBSAG2.

Success After Correction:

  • Following these corrective actions, subsequent manual failover and failback attempts via SSMS were executed seamlessly.

Summary
In summary, this journey through troubleshooting manual failover with error 35208 underscored the importance of the database context, especially when initiating DDL operations. The solution involved a meticulous adjustment of connection options within SSMS, ensuring a connection to the ‘master’ database before attempting manual failover. This article provides a detailed account of the encountered challenge, the thought process behind the solution, and the successful resolution achieved through careful steps and insights.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.