European Windows 2012 Hosting BLOG

BLOG about Windows 2012 Hosting and SQL 2012 Hosting - Dedicated to European Windows Hosting Customer

SQL Server 2016 Hosting - HostForLIFE.eu :: DBCC CLONEDATABASE And Query Store

clock March 27, 2019 09:23 by author Peter

Anyway, by now, you probably have seen documentation on Query Store and DBCC CloneDatabase. Query Store, introduced in SQL Server 2016, is considered the “black box” or “flight recorder” of queries. It retains a history of executed queries, including run-time statistics as well as execution plans from query store enabled databases. This flight recorder helps to diagnosis and pinpoint query performance issues. Another useful tool is DBCC CloneDatabase. This command was released in older versions via service packs before being fully released in 2016. This tool allows you to make a “schema” only copy of a database which will reside on the same server as the source database. The schema includes both user and system schema, as well as any corresponding statistical data.

Why is this useful?
Let’s say you have a 1 terabyte database and wanted to perform query tuning on it. Storage is usually a premium commodity in most organizations and there isn’t a spare terabyte of storage just laying around. DBCC CloneDatabase would allow you to make a schema only copy, including statistics. Once the new database has been created, you could move the new database onto another server without having the requirement of large amounts of storage. Since the database is really a schema-only copy, the footprint of the database is pretty small. After moving the database, queries ran against it would utilize the statistics contained within to execute the query. True, there isn’t any data in the database, but you can account for that when performing query performance analysis.

DBCC CLONEDATABASE (source_database_name, target_database_name) WITH [NO_STATISTICS],[NO_QUERYSTORE],[VERIFY_CLONEDB],[BACKUP_CLONEDB]

  • NO_STATISTICS
    This option specifies that table/index statistics are excluded. Available with SQL Server 2014 SP2 CU3 & SQL Server 2016 SP1

  • NO_QUERYSTORE
    This option specifies that query store data is excluded. Available with SQL Server 2016 SP1

  • VERIFY_CLONEDB
    Verifies the consistency of the new cloned database. Available starting with SQL Server 2016 SP2

  • BACKUP_CLONEDB
    Creates and verifies a backup of the newly cloned database. Available starting with SQL Server 2016 SP2

The command works in this order,

  1. Creates a new destination database. Same file layout as the source database however with the default file sizes from Model.
  2. Generates a snapshot of the source database.
  3. Copies the system metadata from the source to the target database created in step 1.
  4. All object schema is copied from the source to the target.
  5. Index statistics are copied from the source to the target.

Fairly easy and straightforward. But wait! There’s more!

You will notice the “WITH NO_QUERYSTORE” option in the command. If you are running SQL Server 2016 SP1 or higher and utilizing the Query Store for the source database, DBCC CloneDatabase will also bring over the query store data! This is enabled by default so if you do not want the query store data, you have to explicitly define using NO_QUERYSTORE. This means, by default, if you clone a database you will get the flight recorder data from the query store as well.

These two tools, query store and DBCC CloneDatabase, are just another means to help troubleshoot performance issues.

HostForLIFE.eu SQL Server 2016 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.



SQL Server 2016 Hosting - HostForLIFE.eu :: Encrypt And Decrypt Column Data In SQL Server

clock March 13, 2019 09:26 by author Peter

Recently, I worked on a project to hide sensitive data. Basically, the client wanted sensitive data to be encrypted, then accessed and decrypted by the application only. In case a hacker or an employee or a DBA accesses data directly, they can't read the field. Some perfect examples are customer's credit card number, date of birth, social security, or even medical records.

SQL Server provides a feature that allows DBAs and data developers to encrypt and save encrypted data on a column level. Once a column is encrypted, it's not readable by humans.

In this blog, let's see how this can be acheieved.
In the below example, I have used the Credit Card Number column to be encrypted.

You need to write a stored procedure to execute a set of statements and queries. Though it is not a foolproof way to encrypt or decrypt at the database level, while working on this task, I learned some good techniques and features of SQL Server.

There are 3 major factors to encrypt data at the column level, as below.

  • Master Key -  a key which is used to protect the keys of certificates and symmetric keys in the database
  • Certificates - used to encrypt the data in the database
  • Symmetric Key - can be encrypted by using many options, like certificate, password, symmetric key. There are different algorithms available for encrypting a key. The supported algorithms are DES, TRIPLE_DES, RC2, RC4, RC4_128, DESX, AES_128, AES_192, and AES_256.

So, let's start step by step and achieve the encryption and decryption.

Step 1
Create a Master Key first with the help of the below script.
use TestingDB; //This is the Test Database created.  
Create master key encryption by password ='abc123' 


Step 2
Once the Master Key is created, now it's time to create a Certificate.
Create certificate C1 with subject = 'Credit Card Data'

Step 3
Now with the help of certificate and master key create SYMMETRIC KEY.
Create symmetric key SK1 with algorithm = AES_256 encryption by certificate C1.
Once all these KEYs are created in the database, we can use those for encrypting and decrypting data.

Below is the script to encrypt the data in the column. Here I have created one TABLE named TestEncryption having 3 columns with its datatype as below. Note that the column in which we want to insert or update encrypted data should have VARBINARY as the datatype.

Id - INT
EncryptedCCNumber - varbinary (256)
CCNumber - Numeric(18,0)


Let's insert data in the column of the table,
Open symmetric key SK1
Decryption by certificate C1
insert into TestEncryption(Id, EncryptedCCNumber, CCNumber) values (1, ENCRYPTBYKEY(key_guid('SK1'),'5000'), '5000')

Close symmetric key SK1
Now it's time to check if the data is encrypted or not so when you execute a simple query you will get the data from the Table as it is.
select * from TestEncryption 

IF you want to DECRYPT the data you can use the below script
Open symmetric key SK1
Decryption by certificate C1
select *, convert(varchar, DECRYPTBYKEY(EncryptedCCNumber)) as 'Decrypted CC Number' from TestEncryption

Close symmetric key SK1
You will get an extra column named "Decrypted CC Number". This way we can insert/update and select the encrypted data from the table in SQL Server.

HostForLIFE.eu SQL Server 2016 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.



SQL Server 2016 Hosting - HostForLIFE.eu :: About Views in SQL Server

clock March 6, 2019 10:06 by author Peter

What a View is
A view is a virtual table in the database whose contents are defined by a query.
A view appears just like a real table, with a set of named columns and rows of data. Unlike a real table, a view does not exist in the database as a stored set of data values. Instead, the rows and columns of data are generated from the query results defined by the View.

Types of Views in SQL Server
System Views

  • Information Schema View.
  • Catalog view
  • Dynamic Management View (DMV)

User Defined Views

  • Simple View
  • Complex View

create table Authors 

AuthordId int, 
AuthorName varchar(Max), 
Article varchar (Max), 
AuthorRank int 

-------Inserting Data into Authors Table---- 
Insert into Authors values (1,'Mahesh Chand','C# fundamentals',1) 
Insert into Authors values (2,'PraveenKumar','Wpf',20) 
Insert into Authors values (3,'Dhananjaykumar','windowsApplication',3) 
Insert into Authors values (4,'PinalDeve','SqlTrace',4) 
Insert into Authors values (5,'Abhinav','oops',2) 
Insert into Authors values (6,'Abhijit','WCF',5) 
Insert into Authors values (7,'Amit','DatabaseMirroring',7) 
Insert into Authors values (8,'Karthik','ssis',8) 
Insert into Authors values (9,'Divya','WebApi',9) 

(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)


System Views

System Views are predefined Views that already exist in the Master database of SQL Server. These System Views are used as template Views for all newly created databases. These system Views will be automatically created for any user defined database.

Information Schema View
The Information Schema Views are used to display information of a database, such as tables and columns. In SQL Server there are nearly twenty different Information Schema Views.
Example: To determine the complete information of an Authors table using an Information Schema View:
---To see the detail information of Authors Table 
Select * from INFORMATION_SCHEMA.COLUMNS where TABLE_NAME='Authors' 

TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME
C#Corner dbo Authors AuthordId
C#Corner dbo Authors AuthorName
C#Corner dbo Authors Article
C#Corner dbo Authors AuthorRank

Catalog view
Catalog Views are used to show database self-describing information.
Catalog views are also used to return information that is used by the SQL Database Engine like objects, logins permissions and so on.

Example:

  1. --For list of all Views in a Database  
  2. select * from sys.all_views  
  3. ---For list of tables in a database  
  4. select * from sys.tables 

Dynamic Management View (DMV)
DMVs are introduced in SQL Server 2005.
DMVs gives the database administration information about the current state of SQL Server machine on various aspects.
DMVs are easier to detect the health of SQL Server using these views.
DMVs replace many of the DBCC Commands.
All Dynamic Management Views (DMVs) exist in the sys schema and follow this naming convention dm_*.
There are two types of DMVs.

1. Server-scoped DMV
Server-scoped DMVs are Stored in Master Database.
Server-scoped DMVs are used to for the state of an entire SQL Server instance.
Server-scoped DMVs require VIEW SERVER STATE PERMISSION on the server.

2. Database-scoped DMV
Database-scoped DMVs are stored specific to each database.
Database-scoped DMVs require DATABASE STATE PERMISSION on the database.

The following are some of the Dynamic Management Views:
Sys.dm_exec_Cached_plans: Returns the information about query Execution Plans that are cached by SQL-SERVER for faster query execution.
Sys.dm_exec_Query_plan: Returns the show plan in XML format for a T-SQL batch.
Sys.dm_exec_Query_stats: Returns aggregate performance statistics for Cached Query Plans.
Sys.dm_exec_requests: Returns information about each request that is executing within SQL Server.

User Defined Views
These are the views that are defined by the user as per the their requirements.

Simple view
A simple view is one that can be addressed by DML statements as well as SELECT. As might be expected, simple views are based on relatively simple SELECT statements.
It can be used for retrieving data, as well as updating or deleting rows. Rows updated or deleted in the view are updated or deleted data in the table the view was created with. It should also be noted that as data in the original table data changes.
A simple view can be created from a single table.
A simple view does not contain functions.
A simple view does not contain a group of data.

Complex View
We use Complex Views when we want to display data from two or more tables, using a group cluase or a grouping of aggregate functions.
A Complex View can be created from one or more table.
A Complex View contains functions.
A Complex View contains a group of data,

Creating Views
We can create views in 2 ways.

  1. Through Query Designer.
  2. Through Database

Through Query Designer
Database views are created using the CREATE VIEW statement. Views can be created from a single table, multiple tables, or another view.
Syntax:
Create view view_Name
As
....Ur Query.....

Example:
Create view Authors Info

As
Select AuthorName,Article,Rank from Authors

Using SQL Server Management Studio

To create a view using the Query and View Designers:

  1. In Object Explorer, expand the database where you want to create your new view.
  2. Right-click the Views folder, then click New View.
  3. In the Add Table dialog box, select the table that you want to include in your new view from one of the following tabs: Tables, Views, Functions, and Synonyms.
  4. Click Add, then click Close.
  5. In the Query Design Pane, select the columns or other elements to include in the new view.
  6. In the Criteria Pane, select additional sort or filter criteria for the columns.
  7. On the File menu, click Save view name.
  8. In the Choose Name dialog box, enter a name for the new view and click OK.

HostForLIFE.eu SQL Server 2016 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.



SQL Server 2016 Hosting - HostForLIFE.eu :: Difference Between TRUNCATE, DELETE, And DROP In SQL Server

clock February 27, 2019 11:25 by author Peter

The difference between TRUNCATE, DELETE, and DROP is one of the most common interview question. Here are some of the common differences between them.

TRUNCATE

TRUNCATE SQL query removes all rows from a table, without logging the individual row deletions.

The following example removes all data from the Customers table.

TRUNCATE TABLE Customers;  
TRUNCATE is a DDL command
TRUNCATE is executed using a table lock and whole table is locked for remove all records.
We cannot use WHERE clause with TRUNCATE.
TRUNCATE removes all rows from a table.
Minimal logging in transaction log, so it is performance wise faster.
TRUNCATE TABLE removes the data by deallocating the data pages used to store the table data and records only the page deallocations in the transaction log.
Identify column is reset to its seed value if table contains any identity column.
To use Truncate on a table you need at least ALTER permission on the table.
Truncate uses the less transaction space than Delete statement.
Truncate cannot be used with indexed views.
TRUNCATE is faster than DELETE.

DELETE
To execute a DELETE queue, delete permissions are required on the target table. If you need to use a WHERE clause in a DELETE, select permissions are required as well.

The following query deletes all rows from the Customers table. 
DELETE FROM Customers; 
GO


The following SQL query deletes all rows from the Customers table where OrderID is greater than 1000.

DELETE FROM Customers WHERE OrderId > 1000; 
GO 


DELETE is a DML command.
DELETE is executed using a row lock, each row in the table is locked for deletion.
We can use where clause with DELETE to filter & delete specific records.
The DELETE command is used to remove rows from a table based on WHERE condition.
It maintain the log, so it slower than TRUNCATE.
The DELETE statement removes rows one at a time and records an entry in the transaction log for each deleted row.
Identity of column keep DELETE retain the identity.
To use Delete you need DELETE permission on the table.
Delete uses the more transaction space than Truncate statement.
Delete can be used with indexed views.

DROP
DROP table query removes one or more table definitions and all data, indexes, triggers, constraints, and permission specifications for those tables. DROP command requires ALTER permission on the schema to which the table belongs, CONTROL permission on the table, or membership in the db_ddladmin fixed database role.

The following SQL query drops the Customers table and its data and indexes from the current database.
DROP TABLE Customers ; 

The DROP command removes a table from the database.
All the tables' rows, indexes and privileges will also be removed.
No DML triggers will be fired.
The operation cannot be rolled back.
DROP and TRUNCATE are DDL commands, whereas DELETE is a DML command.
DELETE operations can be rolled back (undone), while DROP and TRUNCATE operations cannot be rolled back

HostForLIFE.eu SQL Server 2016 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.

 



SQL Server 2016 Hosting - HostForLIFE.eu :: TRIM Function In SQL Server 2017

clock February 20, 2019 10:22 by author Peter

With the release of SQL Server 2017, a new TRIM() is also introduced which helps to remove the white space/characters from both sides of a string. Before 2017, this functionality was achieved by using the following SQL functions.
    REPLACE - used o replace a character from a string
    LTRIM - trim the white spaces from the left side of a string
    RTRIM - trim the white spaces from the right side of a string

I can explain the functionality with two scenarios.

Let's assume, we have a string named ' ABC ' and we are going to eliminate the white spaces from both sides of the string.
 
In SQL, we usually use the LTRIM and RTRIM function like in the code below.
    SELECT LTRIM( RTRIM(' ABC ')) 

Now, this can be done by using a single TRIM function.
    SELECT TRIM(' ABC ') 

Test results from SSMS can be seen below.

Assume we have a string named 'X ABC Y' and we need to extract 'ABC' from that. As usual, we will go with the REPLACE function as follows.
    SELECT REPLACE(REPLACE('X ABC Y','X ',''),' Y','') 

Here you go with the TRIM function.
    SELECT TRIM('XY ' FROM 'X ABC Y') 

Test results from SSMS are shown below.

Note - It is necessary that you have to mention the trailing charter in the TRIM function, otherwise, this will not work as expected.
 
For example, if you try to remove the 'white space' only from the string 'X  ABC  Y', then TRIM will not help you. Similarly,  if you don't mention the letter 'Y', TRIM will not remove the white space after the string, even though you already mentioned the 'X' and the 'white space' characters inside the TRIM function. See these scenarios in the below screenshot.
 
Test results from SSMS,

HostForLIFE.eu SQL Server 2016 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.



SQL Server 2016 Hosting - HostForLIFE.eu :: Brief Introduction To Indexes In SQL Server

clock February 12, 2019 10:42 by author Peter

If you want to find a record in a table without having an index, the system will scan the whole table to get that record. Well, this is a very costly operation in terms of time. For example, if your table has 10 million records, it will scan all these records to find the value. To overcome this problem, indexes are used. Indexes use the B-TREE search algorithm to search a record in a table, which is way faster than the table scan.

Types of Index
Below are the frequently used types of Indexes.

  • Clustered Index
    A clustered index is an index that defines the physical order of records to be stored in a table. Therefore, the table can have only one clustered index. 
  • Non-Clustered Index
    A non-clustered index is similar to an index in a book. The data is stored in one place and the index is stored in another place. Here, the index has pointers to the storage location of the data. Therefore, a table can have more than one Non-clustered index. 
The syntax for creating an index.
CREATE INDEX <Index Name>  
ON <Table Name> (<Column Name>);  
  
/*Example of creating index on Lastname column of Persons table*/  
  
CREATE INDEX idx_lastname  
ON Persons (LastName); 

Benefits of indexing foreign key columns

There are two primary benefits of using the Index on foreign key.
  1. Makes delete operation of parent table faster
    When you delete a row from a parent table, the SQL Server checks if there are any rows which reference the row being deleted in the child table. To find the rows efficiently, an index on the foreign key column is extremely useful.
  2. Making joins faster
    Using Index, SQL Server can more effectively find the rows to join to when the child and parent tables are joined.

Can we have multiple indexes on the same column?

  • As you can have only one clustered index per table, you cannot have multiple clustered indexes on the same column; however, you can have multiple non-clustered indices on the same column.

HostForLIFE.eu SQL Server 2016 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.



SQL Server 2016 Hosting - HostForLIFE.eu :: How to Scheduling Things To Run In SQL Server?

clock January 23, 2019 10:21 by author Peter

A key part of the SQL Server Agent is the ability to schedule jobs. While you can create one schedule for each agent job, frequently with applications like Reporting Services, users use Shared Schedules across multiple jobs. For instance, you can set a schedule to run at 8 am on week days or run every 2 hours or pick from a predefined list of schedules that already exist in the MSDB database. These are very convenient. However, if you choose to use these be sure you are keeping track of what is running for each of these shared schedules. You should not have everything running at once.

This is an example of a job schedule in a Management Studio SQL Server Agent Job. You can create a new one or pick from a list of already made schedules.

There’s nothing inherently wrong with using shared schedules—some very small operations can all run at the same time, however when you start to use them for larger operations you can really impact the overall performance of your server.

Many times, I have seen high CPU or locks as well as many other performance issues due to the system being overloaded with jobs running on shared schedules or all at the same time (midnight is a frequently common choice). Not every report to should run at 8 am and every data load run every 2 hours. If you not using shared schedules or added a separate schedule per job it is also important to make sure you are not running up against other things running. If you are using applications like SSRS, then you need to pay attention to when the report subscription refreshes are happening. Don’t overload your system by having everything run at once. Job and subscription schedules need to be analyzed and evaluated just like everything else you care for in your database.

To keep this from happening consult your agent jobs to see what other jobs are running before scheduling additional ones. You can easily get a glimpse in Job activity monitor to see what’s running and when it will run next.

HostForLIFE.eu SQL Server 2016 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.



SQL Server 2016 Hosting - HostForLIFE.eu :: ASCII Values Of Alphabets And Numbers In SQL Server

clock January 11, 2019 11:10 by author Peter

To find the ASCII value of an alphabet or a number, we can use ASCII function in SQL Server. We will see how to get the ASCII value of numbers from 0-9 and uppercase and lowercase alphabets.

What is ASCII?
ASCII (American Standard Code for Information Interchange) is the most common format for text files in computers and on the internet. In an ASCII file, each alphabetic, numeric, or special character is represented with a 7-bit binary number (a string of seven 0s or 1s). There can be 128 possible characters defined. It serves as a character encoding standard for modern computers.

Syntax
ASCII ( ‘character_expression’ )

ASCII value of capital A is 65 and Z 90.
    SELECT ASCII('A') 
    SELECT ASCII('Z') 


To find the ASCII values of alphabets from A to Z, use this code.

    DECLARE @Start int 
    set @Start=65 
    while(@Start<=90) 
    begin 
    print char(@Start) 
    set @Start=@Start+1 
    end 


To find the ASCII values of characters from a to z, we can use this query.
    SELECT ASCII('a') 
     
    SELECT ASCII('z') 
     
    DECLARE @Start int 
    set @Start=97 
    while(@Start<=122) 
    begin 
    print char(@Start) 
    set @Start=@Start+1 
    end 

ASCII Values Of Alphabets And Number In SQL Server

To find the ASCII value of numbers from 0 to 9, we can use this query.
    SELECT ASCII(9) 
     
    SELECT ASCII(0) 
     
    DECLARE @Start int 
    set @Start=48 
    while(@Start<=57) 
    begin 
    print char(@Start) 
    set @Start=@Start+1 
    end

HostForLIFE.eu SQL Server 2016 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.



SQL Server 2016 Hosting - HostForLIFE.eu :: APPROX_COUNT_DISTINCT Function In SQL

clock January 7, 2019 11:13 by author Peter

Approximate COUNT DISTINCT

We all have written queries that use COUNT DISTINCT to get the unique number of non-NULL values from a table. This process can generate a noticeable performance hit especially for larger tables with millions of rows. Many times, there is no way around this. To help mitigate this overhead SQL Server 2019 introduces us to approximating the distinct count with the new APPROX_COUNT_DISTINCT function. The function approximates the count within a 2% precision to the actual answer at a fraction of the time.

Let’s see this in action.
In this example, I am using the AdventureworksDW2016CTP3 sample database which you can download here.
    SET STATISTICS IO ON 
    SELECT COUNT(DISTINCT([SalesOrderNumber])) as DISTINCTCOUNT 
    FROM [dbo].[FactResellerSalesXL_PageCompressed] 


SQL Server Execution Times
CPU time = 3828 ms, elapsed time = 14281 ms.
    SELECT APPROX_COUNT_DISTINCT ( [SalesOrderNumber]) as APPROX_DISTINCTCOUNT 
    FROM [dbo].[FactResellerSalesXL_PageCompressed] 


SQL Server Execution Times
CPU time = 7390 ms, elapsed time = 4071 ms.

APPROX_COUNT_DISTINCT Function In SQL

You can see the elapsed time is significantly lower! Great improvement using this new function.

The first time I did this, I did it wrong. A silly typo with a major result difference. So take a moment and learn from my mistake.

Note that I use COUNT(DISTINCT(SalesOrderNumber)) not DISTINCT COUNT (SalesOrderNumber ). This makes all the difference. If you do it wrong, the numbers will be way off as you can see from the below result set. You’ll also find that the APPROX_DISTINCTCOUNT will return much slower than the Distinct Count; which is not expected.

APPROX_COUNT_DISTINCT Function In SQL

Remember COUNT(DISTINCT expression) evaluates the expression for each row in a group and returns the number of unique, non-null values, which is what APPROX_COUNT_DISTINCT does. DISTINCT COUNT (expression) just returns a row count of the expression, there is nothing DISTINCT about it.

HostForLIFE.eu SQL Server 2016 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.

 



SQL Server 2016 Hosting - HostForLIFE.eu :: SQL Server Development Best Practices Guide

clock December 19, 2018 10:13 by author Peter

Coding is always a fun but challenging job. Developers do not only have to execute the right output based on the business requirement but also need to maintain the right coding standards by using the optimum use of variable sizes and keeping in view the other best practices. I am going to provide a list of best practices and guidelines today, in this article. Many of us already may have been using these but I thought to gather those in a single page so that while developing, the code can be useful, keeping the standard intact.
Application to be used,

  • Developers need to use the Developer Edition of the SQL Server edition rather than using SQL Express or Enterprise edition.

Database Design

  • Ensure that the referential integrity is maintained at all the times, i.e., the relationship between Primary Key and Foreign Key.
  • Always specify the narrowest columns you can. In addition, always choose the smallest data type you need to hold the data you need to store in a column. The narrower the column, the less amount of data SQL Server must store, and the faster SQL Server is able to read and write data.

Database Configuration Settings

  • Create proper database file sizes (this includes Initial DB file size and growth values)
  • Maintaining consistency in DB filegroups across the markets.

Data modeling

  • Use of appropriate data types and length while the data models are created (limit using blob data types unless really needed). The narrower the column, the less amount of data SQL Server must store, and the faster SQL Server is able to read and write data.

Performance/Load Tests

  • While performing perf tests, adjusts the database file sizes accordingly. Suspend the maintenance jobs during the period.

Purging solution

  • Checking with the business team over a period to implement the correct data purging solutions which best fits your environment.

Database Objects

  • Use user-defined constraint names rather using system-generated names.
  • Use database objects to sit in the respective defined Filegroups. Avoid getting the user objects and data to sit in the system/primary filegroup.

Indexing

  • Appropriate Index Naming convention.
  • Appropriate use of Case while creating objects such as tables, indexes and other objects.
  • Use the appropriate column sequence while creating the index schema.
  • Try to avoid creating duplicate indexes.
  • Limit use of filtered indexes unless you are sure that can give you real benefits.
  • When creating a composite index, and when all other considerations are equal, make the most selective column in the first column of the index.
  • keep the “width” of your indexes as narrow as possible. This reduces the size of the index and reduces the number of disks I/O reads required to read the index, boosting performance.
  • Avoid adding a clustered index to a GUID column (unique identifier data type). GUIDs take up 16-bytes of storage, more than an Identify column, which makes the index larger, which increases I/O reads, which can hurt performance.
  • Indexes should be considered on all columns that are frequently accessed by the JOIN, WHERE, ORDER BY, GROUP BY, TOP, and DISTINCT clauses.
  • Don't automatically add indexes on a table because it seems like the right thing to do. Only add indexes if you know that they will be used by queries run against the table. Always assess your workload before creating the right indexes.
  • When creating indexes, try to make them unique indexes if possible. SQL Server can often search through a unique index faster than a non-unique index because in a unique index, each row is unique, and once the needed record is found, SQL Server doesn't have to look any further.

Properties of Indexes

  • Don’t automatically accept the default value of 100 for the fill factor for your indexes. It may or may not best meet your needs. A high fill factor is good for seldom changed data, but highly modified data needs a lower fill factor to reduce page splitting.

Transact-SQL

  • If you perform regular joins between two or more tables in your queries, performance will be optimized if each of the joined columns has appropriate indexes.
  • Don't over-index your OLTP tables, as every index you add increases the time it takes to perform INSERTS, UPDATES, and DELETES. There is a fine line between having the ideal number of indexes (for SELECTs) and the ideal number to minimize the overhead that occurs with indexes during data modifications.
  • If you know that your application will be performing the same query over and over on the same table, consider creating a non-clustered covering index on the table. A covering index, which is a form of a composite index, includes all the columns referenced in SELECT, JOIN, and WHERE clauses of a query. Because of this, the index contains the data you are looking for and SQL Server doesn't have to look up the actual data in the table, reducing I/O, and boosting performance.
  • Remove encryption from table columns where it is not necessary at all. Overuse of encryption can lead to poor performance. Check with business users time to time on this to ensure right table columns are only considered for encryption.

Version control/source control

  • Maintain all code in a source control system and update it always for all type of changes happening to the code base.

Queries and Stored Procedures

  • Keep the transactions as short as possible. This reduces locking and increases the application concurrency, which helps to boost the performance.
  • If needed to run SQL commands use only designated columns rather using * to fetch all the commands and use the TOP operator to limit the number of records.
  • Avoid using query hints unless you know exactly what you are doing, and you have verified that the hint boosts performance. Instead, use the right isolation levels.
  • SET NOCOUNT ON at the beginning of each stored procedure you write.
  • Do not unnecessarily use select statements in the code block if you do not want to send any result back to display.
  • Avoid such code which can lead to unnecessary network calls. Check the count of the code block and verify if those many calls are really needed.
  • When using the UNION statement, keep in mind that, by default, it performs the equivalent of a SELECT DISTINCT on the result set. In other words, UNION takes the results of two like record sets, combines them, and then performs a SELECT DISTINCT in order to eliminate any duplicate rows. This process occurs even if there are no duplicate records in the final recordset. If you know that there are duplicate records, and this presents a problem for your application, then use the UNION statement to eliminate the duplicate rows.
  • If you see there is a necessity to use Upper () or Lower () functions or need to use LTRIM () or RTRIM () functions, it will be better to modify the data corrected while accepting the user inputs from the application side rather performing changes in the script. This will make the queries to run faster.
  • Carefully evaluate whether your SELECT query needs the DISTINCT clause or not. Some developers automatically add this clause to every one of their SELECT statements, even when it is not necessary.
  • In your queries, don't return column data you don't need. For example, you should not use SELECT * to return all the columns from a table if you don't need all the data from every column. In addition, using SELECT * may prevent the use of covering indexes, further potentially hurting query performance.
  • Always include a WHERE clause in your SELECT statement to narrow the number of rows returned. Only return those rows you need.
  • If your application allows users to run queries, but you are unable in your application to easily prevent users from returning hundreds, even thousands of unnecessary rows of data, consider using the TOP operator within the SELECT statement. This way, you can limit how many rows are returned, even if the user doesn't enter any criteria to help reduce the number of rows returned to the client.
  • Try to avoid WHERE clauses that are non-sargable. If a WHERE clause is sargable, this means that it can take advantage of an index (assuming one is available) to speed completion of the query. If a WHERE clause is non-sargable, this means that the WHERE clause (or at least part of it) cannot take advantage of an index, instead of performing a table/index scan, which may cause the query's performance to suffer. Non-sargable search arguments in the WHERE clause, such as "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'" generally prevents (but not always) the query optimizer from using an index to perform a search. In addition, expressions that include a function on a column, expressions that have the same column on both sides of the operator, or comparisons against a column (not a constant), are not sargable. In such case, break the code appropriately so that a proper index or set of indexes can be used.
  • If using temporary tables to keep the backup of the existing large tables in the database, remove them as and when the task is needed as those contain a lot of storage and the maintenance plan will take more time to complete as because those tables will be considered for maintenance as well.
  • Do not use special characters or use them very carefully while passing them via a stored procedure. It might change the query execution plan and lead to poor performance. Often the situation is known as Parameter sniffing.
  • Avoid SQL server to do an implicit conversion of data, rather use it appropriately (use explicit code-based conversion).

SQL Server CLR
The Common language runtime (CLR) feature allows you to write stored procedures/trigger/functions in .NET managed code and execute the same from SQL Server.

  • Use the CLR to complement Transact-SQL code, not to replace it.
  • Standard data access, such as SELECT, INSERTs, UPDATEs, and DELETEs are best done via Transact-SQL code, not the CLR.
  • Computationally or procedurally intensive business logic can often be encapsulated as functions running in the CLR.
  • Use CLR for error handling, as it is more robust than what Transact-SQL offers.
  • Use CLR for string manipulation, as it is generally faster than using Transact-SQL.
  • Use CLR when you need to take advantage of the large base class library.
  • Use CLR when you want to access external resources, such as the file system, Event Log, a web service, or the registry.
  • Set CLR code access security to the most restrictive permissions as possible.

Consultation

  • You can also a consultant with your in-house DBAs for any advice about Microsoft Best Practices and standard or use of correct indexes to be used.
  • You can seek training from any good external training providers.
  • Another good option is to use good third-party tools such as RedGate, FogLight, Idera, SQLSentry, SolarWinds and check the performance of the environment by monitoring the scripts.

Process Improvement

  • Document common mistakes in the Lessoned Learned page per the PMP best practice guidelines.
  • Do check out the new upcoming editions and try to align your code accordingly.

Hope that the above-advised guidelines would be useful. Do share if you use any other steps in your workplace which is found to be helpful.

HostForLIFE.eu SQL Server 2016 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.



About HostForLIFE.eu

HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes.

We have offered the latest Windows 2016 Hosting, ASP.NET Core 2.2.1 Hosting, ASP.NET MVC 6 Hosting and SQL 2017 Hosting.


Tag cloud

Sign in