This article is dedicated to a slightly more complex product analysis with Full-Text Search as opposed to the first part where we looked at how to perform a basic product analysis.Read More
For a SQL database developer, it is essential to have the necessary SQL tools in hand, which enable to reduce the development time of given functionality. The same is true for the tester. For a database administrator, it is also important to have monitoring tools.
In this article, we are going to look at some MS SQL Server development and monitoring tools, such as:
When working on the release of dbForge Transaction Log, among other tasks, our team had to puzzle out how to properly store typed XML data.
To start with, it is worth mentioning that SQL Server does not store XML in the format it was entered. An XML string is parsed, split to tags, and thus is stored in a compressed format. Description elements that the server considers unnecessary are discarded.
JSON – A Brief Background
JSON is also used extensively in NoSQL databases such as the increasingly popular MongoDB. Virtually all the Social Media giants expose APIs that are based on JSON. I am sure you begin to get the idea of how widespread its applications have become. JSON was standardized in 2013 and the latest version of the standard (ECMA-404: The JSON Data Interchange Syntax) was released in 2017.
SQL Server introduced support for JSON in SQL Server 2016.
In my previous articles, I have explained the step-by-step process of deploying an AlwaysOn Availability group on SQL Server 2017. In this article, I am going to explain how to monitor AlwaysOn availability groups.
First, let’s review the configuration of the availability group we had deployed previously. To do that, open SQL Server Management Studio Expand database engine from the object explorer Expand “AlwaysOn High Availability” Expand “Availability Groups.” You can see the availability group named SQLAAG. Under this availability group (SQLAAG), you can see the list of availability replicas, availability databases, and availability group listeners. Read More
If you are a SQL Server database administrator or developer, you need to frequently search for specific database objects the names of which you can only partly remember. The manual approach to performing these search operations is time-consuming, especially when the database has a large number of objects.
Another scenario is one in which you want to search for specific data in all database tables. In this case, you need to run a SELECT statement multiple times based on the number of database tables or views you want to search in, or write a complex cursor to loop and search in all database tables, which requires advanced SQL Server development skills.
In this article, we will look at different ways of searching for a specific database object or data in SQL Server, going gradually from built-in methods and diving into a 3rd-party tool that makes it a piece of cake to get the requested database object or data. Read More
An Overview of Traditional Recovery
As with all relational database systems, SQL Server guarantees the durability of data by implementing crash recovery. Durability in the acronym ACID which refers to the characteristics of transactions in relational databases means that we can be assured that if the database fails suddenly, our data is safe.
SQL Server implements this capability using the transaction log. Changes made by all Data Manipulation Operations in SQL Server are captured in the transaction log before being applied to data files (through the checkpoint process) in case it’s needed to roll back or roll forward.
In my previous article, I have explained the step-by-step process of installing SQL Server Failover Clustered Instance. In this article, I will explain how to add a secondary node to the existing failover clustered instance.
Install SQL Server Failover Cluster instance
Once SQL Server is installed on an SQL01.dc.Local node, connect to SQL02.dc.Local and run setup.exe – SQL Server installation wizard opens. In the wizard, select “Installation” from the panel on the left and click on “Add node to a SQL Server failover cluster”. See the following image:
In my previous article, I have explained the process of installing and creating a failover cluster and how to enable the AlwaysOn availability group.
In this article, I am going to explain the step-by-step deployment process of SQL Server AlwaysOn Availability groups using wizards. The deployment configurations look the following way:
In this article, I will explain the process of installing pre-requisites to deploy the SQL Server AlwaysOn availability group.
For the demonstration, I have prepared a demo set up at my work station. See the following components:
|Virtual Machine||Host Name||Purpose|
|Domain Controller||DC.Local||The domain controller is installed on this machine|
|Primary Replica||SQL01.DC.Local||This machine acts as a Primary replica in the Availability group|
|Secondary Replica||SQL02.DC.Local||This machine acts as a Secondary replica in the Availability group. This replica is in a Synchronous commit mode|
|Secondary Replica with||SQL03.DC.Local||This machine acts as a secondary replica in the Availability group. This replica is in an Asynchronous commit mode|
I will explain the following actions:
- Installing a failover clustering role
- Create a failover cluster
- Enable AlwaysOn availability group features in SQL Server