Different offers from Microsoft Azure for SQL Server

SQLServerF1

Cloud solutions has been gaining increased support and many customers moving their data on to cloud technologies or planning to move in future. The reason for increase in popularity of the cloud technologies include that it reduces the operational and maintenance cost of hosting the own hardware and its day to day maintenance. Many operation tasks such as backups, patching, etc can also be taken care by the cloud solutions depending on the kind of offering selected. Microsoft and other companies like Amazon are investing a lot on the cloud technologies and trying to provide features that match the on-premise servers and applications or more than that.

Microsoft is offering its cloud services in different types depending on the services offered. These include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). These offerings are generic and is applicable for different applications which include SQL Server too. Coming specifically to SQL Server, Microsoft is offering two services SQL Server on Azure VMs (IaaS) and SQL Azure Database (PaaS).
SQL Server on Azure VMs (IaaS) – This is similar to on-premise SQL Server running on a virtual machine which is running on a host system whose hardware is maintained in Microsoft’s data center. In on-premise servers, DBAs or management discuss and decide on the hardware required like CPU, Memory and storage and the Operating System required, on top of which DBAs install SQL Server instances and create or restore databases. in SQL Server on Azure VMs (IaaS), Microsoft provides required hardware(CPU, Memory, Storage) and provides a VM with required Operating System too. DBAs can install SQL Server instance on this VM, configure and manage and administer it just like an on-premise SQL Server instance. If any support is required related to hardware, then DBAs are required to contact the Microsoft support. This is best suited for applications which does not need much changes after moving to cloud technology and where management want more control on the SQL Server.

SQL Azure Database (PaaS) – SQL Azure on the other hand is a Database as a Service offering of SQL Server. This SQL Server runs on a VM which is maintained by Microsoft and this server will be hosted on Microsoft Data Center. In this offering DBAs does not need to install, or manage things like patches, backups, upgrades, etc, as these things are taken care by Microsoft team either through automated scheduled tools to by manual maintenance depending on the type of the task. There are many things which are offloaded from DBA like high availability, disaster recovery, patch maintenance, etc. If high availability is required, we need to choose the right offering and license which provides the high availability. Here we can choose which server needs which features and based on the features used and the usage the price will be decided. DBAs or managers get access to Azure portal where we can setup new SQL Azure instances, configure them, choose required features, and find the connection strings to be used in the application or to use in SSMS to connect to this instance locally from out laptop or other devices. From SSMS or other applications, we can create databases, tables, users, etc and use the databases to store and retrieve the data. This is best suited for new applications which just need access to data and does not want to spend time and efforts on maintaining SQL Server like backups, patches, high availability, etc. One of the major limitation in this is that the existing applications are required to be rewritten to able to work on SQL Azure.

During initial stages when the SQL Azure service was introduced, there were lot of limitations, so was not used much, but as in 2015, the offerings have increased a lot and can support many applications to move their data to SQL Azure and use it without much issues. However there are still many limitations, when compared to on-premise SQL Server instances, which almost does not have any limitations.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2008 R2
SQL Server 2012
SQL Server 2014
SQL Server 2016

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

Considerations for SQL Server Instances and Databases for Virtualization

SQLServerF1

Virtualization has growing demand and implementation after many success stories. Previously SQL Server instances were installed on servers with their own physical hardware, but that also introduced challenges of effective usage of the available hardware. Over a period of time, the hardware has dramatic changes which made available high configurations for cheaper price and smaller sizes and servers have become more powerful and can support a lot of CPUs, high amount of memory in terabytes, support for high storage, local, SAN and SSDs. So, virtualizaiton helps in using these powerful tools in an effective manner by allowing to create multiple virtual machine guests on one host server, thus making the hardware usage effectively.

With latest virtualization technologies have their own virtualization operating system which is installed on top of hardware even before the installation of the Windows Server Operating Systems. Once the Virtualization OS is installed, now it allows creation of multiple virtual machines each with certain set of CPU, Memory and Storage. Each VM acts as independent server and any operating system can be installed and any applications can be installed, this helps segregate multiple applications running on server server to running each application on its own virtual machine. When it comes to SQL Server, where the SQL Server instances are spreads cross many different servers need to be consolidated and moved into their own virtual machine or combine multiple databases and host them on their own VM and SQL Server instance.

To consolidate multiple SQL Server instances on different physical servers into their own VM ot on to a single SQL Server instance, we will need to follow a proper approach or consider various options to choose what suits the requirement better. Below are some of the options to consider inorder to choose which databases, instances and servers can be consolidated.

Version upgrade paths – Need to understand if we can group the databases which does not have issues upgrading to higher versions as soon as one is available. If the databases cannot be upgraded and requires lot of planning and testing before hand then such databases are better of to have their own dedicated VMs.
Maintenance Windows – Need to group databases which can have maintenance performed at certain time, such can be hosted on same VM and which have different maintenance times, can be moved to their dedicated VMs.
Security – Databases or applications which require high security are better of hosted on their own VMs.
Performance – Critical servers which require high performance can be left running on its own physical hardware or on a server which is shared by non-critical applications to avoid other servers using high amount of resources from the host server.
High Availability – Databases or applications which are very critical and require high availability needs their own dedicated VMs.
Licensing – If licensing cost needs to be reduced, then need to try and group databases with similar characteristics on one SQL Server instance or few SQL Server instances on different VMS.
Backup and Restore – Databases or applications which require very good planning for recovering data and time taken to recover the data is very small, such are to be hosted on own servers.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2005
SQL Server 2008 R2
SQL Server 2012
SQL Server 2014
SQL Server 2016

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

Introduction to SQLAzure for SQL Server DBAs

SQLServerF1

Microsoft has been aggressively focussing on promoting cloud technology. As a SQL Server DBA, one might wonder what is all about this cloud and how this works and how this impacts their role as a DBA. Although the terminology may be different, but a lot about cloud may already known to you or worked on, but may be not able to correlate to what you already know. For SQL Server Microsoft is offering two cloud platforms, one of which is Infrastructure as a service and the other one is database as a service.

Infrastructure as a service – This is similar like a hyper-v or VMWare VM, where you have a VM machine on which you install and manage SQL Server instances, databases and jobs, etc. The only difference is the VMWARE or Hyper-V management is taken care by your client company or your company, where in case of Microsoft Azure cloud the infrastructure is taken care by Microsoft and as a DBA, we need to take care of installing SQL Server, patching, maintenance, administration similar to what we used to do, but just on a Microsoft data centre.

Database as a service – This might be something different and which many DBAs may not be familiar about. In this the OS, Network, Storage and also SQL Server installation, patching, Backups, etc are taken care by Microsoft and we as DBAs are not responsible for such tasks, instead we can focus on other tasks such as migrating data from on-premise SQL Server to SQL Azure cloud and checking and working on making the SQL Server database resilient for performance. Database as a service is not a regular SQL Server instance which we used to manage on-premise, instead there are lot of limitations on what we can do and what changes we can make, for example, we cannot change many instance settings directly, we cannot alter storage configuration, or tempdb configuration, etc, instead we focus more at the database level and at data level.

If you are wondering what are the advantages for choosing SQLZure cloud solution is mainly reduction in cost of maintaining hardware and SQL Server maintenance of patches/backups, etc. Depending on the criticality of our database server and application, we can choose different kind of licensing based on our requirement of performance, data recovery and Disaster recovery features. So, for small test/dev servers you can choose servers with basic or minimal cost configuration and for productions servers depending on the size and usage of the database we can choose appropriate license. Different types of licensing includes, Basic, Standard and Premium and these are sub divided into S0-S1-S2-S3 for Standard and P1-P2-P3 for Premium.

As our data is stored on cloud on third party vendor place, it is important to understand how quickly we can recover our data and how much of data loss can occur in case there is a disaster, for which there are different types of Disaster recovery strategies to choose from, which include Geo-Restore, Standard Geo-Replication, Active Geo-Replication. In Geo-Restore, a copy of database can be restored on another region, but this will have data older than 24 hours, thus may not be good option for production data, instead can be used for dev. In Standard Geo-Replication, we can recover data up to 30 minutes before crash and can take up to 2 hours for the restore to complete and database to be available, but this will increase the cost. Finally, Active Geo-Replication, the data loss could be reduced to 5 minutes and amount of time to restore would about about an hour, this further increases the cost. Depending on our requirement, we can choose the best solution that suits.

in SQLZure, there is something known as DTU(Database Throughput Unit), which is used to measure the performance we get out of our SQLZure instance. DTU is a combined measure of CPU, Memory and IO of a database on a server and we can use this to compare the performance of database between different servers.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2008 R2
SQL Server 2012
SQL Server 2014
SQL Server 2016

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

Best Practices to run SQL Server on Amazon RDS

SQLServerF1

Amazon Relational Database Service (Amazon RDS) is a web service that makes it easier to set up, operate, and scale a relational database in the cloud. It provides cost-efficient, resizeable capacity for an industry-standard relational database and manages common database administration tasks. Although Amazon RDS is great for many applications to store its data, but has many limitations where many features cannot be used due to restricted permissions at file system level and on registry and OS level.

Although running SQL Server on Amazon reduces cost to great affect, but has its own limitations too and need to review them carefully before moving data to Amazon RDS.

– Always Better to choose Multi-Availability zone deployment to have high availability, as we never know when the instance may go down, so to avoid or reduce the amount of down time, having high availability using Multi-Availability zone deployment will be helpful.
– Plan thoroughly in advance about the CPU, Memory and Storage requirements, changing these later may be complex. Storage cannot be changed once instance is created.
– Choose the proper server level settings,as they can be modified using Parameter Group and can be some what difficult to change and may be required instance to be restarted for few settings changes to apply.
– Patch levels are often controlled by Amazon RDS and may have some known issues due to older version of patches available and can impact your application due to known issues.
– Always choose the database files with proper initial size and auto-growth at higher sizes to avoid growing of files during application usage, this reducing the time and improving performance.
– If you are using Multi-Availability zone deployment, note the amount of time taken for the synchronization, as this is synchronous and thus the time for sync can have significant impact on you data access from application.

There may be other best practices, and following them will help running your databases on Amazon RDS seemless and provide cost effective solution replacing on-premise SQL Server databases. Not considering these limitations can significantly cause timeouts or performance issues and can make you feel frustrated for moving to Amazon RDS. Proper planning and understanding if your application works well on Amazon RDS will decide how the application will behave in future. Also, as time the amount of data can increase and can have significant impact on performance, so it is important to consider server configuration for future data growth and user usage.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2012
SQL Server 2008 R2

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

DBA Tasks Offloaded After Moving to AmazonRDS or SQLAzure

SQLServerF1

Amazon Relational Database Service (Amazon RDS) is a web service that makes it easier to set up, operate, and scale a relational database in the cloud. It provides cost-efficient, resizeable capacity for an industry-standard relational database and manages common database administration tasks. Although Amazon RDS is great for many applications to store its data, but has many limitations where many features cannot be used due to restricted permissions at file system level and on registry and OS level.

For On-Premise SQL Server instances, DBAs and System Admins are responsible for many tasks which may be day to day or some scheduled tasks like patching, maintenance etc. Amazon RDS or SQL Azure can offload many such tasks which SQL Server DBA or System Admin has to take care and thus can reduce the load on the DBAs on large environments with many servers and applications. Instead of spending time on repeated things, they can focus more on other important DBA activities like performance turning, health checks, etc.

Some of the important activities or tasks offloaded from DBAs or System Admins are listed below. These are not the only ones, but there are others too.
Patching – Patching of SQL Server instances or Operating System, drivers, etc have been one of the core responsibilities of the DBAs or System Administrators and often are repeatable and does not require smart work instead requires some hard work on working during off hours to reduce the impact on the users using the application. With Amazon RDS, these patching is taken care by Amazon team and we only have to specify the window on when the patching needs to take place. However this limits the control on what patches can be applied, as every patch we want will not be applied, as they need to certify which patch needs to be applied and tested to work smoothly.

Upgrade to Higher Version – Upgrading on-premise SQL Server is considered one of the major project and requires lot of planning and time to implement and test. With Amazon RDS, the implementation of upgrade and any issues are taken care by Amazon and we can just focus on testing our application and fixing the appliation compatibility issues.

Backups – Backups are taken care by Amazon and we just need to specify the time when backups can be performed and how many days backups are required to be retained. Point to note is that the number of backups to be retained is directly proportional to the increase in storage price to keep the backups. By default recovery model used in SIMPLE and cannot be changed to simple, instead we need to choose retention period as 0, meaning we do not need any backups. Thus, for databases which need backups will have full and transaction log backups and mostly we can recover our data to as early as 5 minutes before the crash.

High Availability – Amazon provides support for High Availability and it is important to choose the high availability feature, as this is third party vendor and on data centre which we have no control or details about, so we never know if there will be any issues or outages. For high availability, RDS can automatically setup a database mirroring secondary on another Availability Zone often in another Amazon data centre in the same region.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2012
SQL Server 2008 R2
SQL Server 2014

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

AmazonRDS SQL Server DB Instance Settings Which Can be Modified

SQLServerF1

Amazon Relational Database Service (Amazon RDS) is a web service that makes it easier to set up, operate, and scale a relational database in the cloud. It provides cost-efficient, resizeable capacity for an industry-standard relational database and manages common database administration tasks. Although Amazon RDS is great for many applications to store its data, but has many limitations where many features cannot be used due to restricted permissions at file system level and on registry and OS level.

AmazonRDS SQL Server DB Instance has various settings which can be modified to suit our requirements. Below are some of the important setting which can be modified after the AmazonRDS SQL Server DB Instance has been created. It is important to understand that modifying these settings can have adverse effect too, so just be careful and fully understand the change which you are making. You can make all these changes listed below from AmazonRDS web console.

DB Engine Version – Used to choose the version of the SQL Server database engine that we want to use.
Multi-AZ Deployment – Allows us to create a standby mirror of our DB instance in another Availability Zone, click Yes, otherwise, click No.
DB Instance Identifier – We can rename our DB instance by providing a new name. When we change the DB instance identifier, instance reboot will occur immediately if we set Apply Immediately to true, or will occur during the next maintenance window if we set Apply Immediately to false.
New Master Password – We can change the master password. By resetting the master password, we also reset permissions for the DB instance.
Security Group – We can choose the security group we want to associate with the Database Instance.

Certificate Authority – We can choose a certificate we want to use.
Publicly Accessible – Selecting Yes allows the DB instance a public IP address, meaning that it will be accessible outside the VPC (the DB instance also needs to be in a public subnet in the VPC), Id we choose No, the the DB instance will only be accessible from inside the VPC.
Parameter Group – Allows us to choose the parameter group we want to associate with the database instance. Changing this setting does not result in an outage. The parameter group name itself is changed immediately, but the actual parameter changes are not applied until you reboot the instance without failover.
Option Group – We can choose the option group which we want to associate with out database instance.
Database Port – We can specify a particular port to use for our Database instance.
Backup Retention Period – We can adjust or modify the database backup retention period. To disable automatic backups, we can set this value to 0(useful for test environments to reduce cost).
Backup Window – We can choose the backup windows, on when the backup of the database needs to be performed. This time is in Universal Coordinated Time (UTC) and a duration in hours.
Auto Minor Version Upgrade – If you want your DB instance to receive minor engine version upgrades automatically when they become available, click Yes. Upgrades are installed only during your scheduled maintenance window.
Maintenance Window – We can set the time range during which system maintenance, including patchs, upgrades, will occur. This is start time in UTC and a duration in hours.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2012
SQL Server 2008 R2

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

How to Connect to AmazonRDS from SQL Server Management Studio?

Amazon Relational Database Service (Amazon RDS) is a web service that makes it easier to set up, operate, and scale a relational database in the cloud. It provides cost-efficient, resizeable capacity for an industry-standard relational database and manages common database administration tasks. Although Amazon RDS is great for many applications to store its data, but has many limitations where many features cannot be used due to restricted permissions at file system level and on registry and OS level.

Although application connect to the database and works fine, it is important for DBAs or Developers to be able to query for data and to manage Databases and other objects places on AmazonRDS. There may be different ways to connect to Amazon RDS and manage or query data, but one of the easiest method and most popular and convenient way is to do it through well known tool which is SQL Server Management Studio(SSMS). We only need few basic details and then we should be good to connect to our database on AmazonRDS.

Firstly we need to create a security group from AmazonRDS web console, and then we must modify the DB instance to associate it with the security group. Once we are done with it, we can follow below steps to be able to connect to our database from SSMS

– On the Instances page of the AWS Management Console, we need to choose the arrow next to the DB instance to show the instance details. Make a note of the server name and port of the DB instance, which are displayed in the Endpoint field at the top of the panel, and the master user name, which is displayed in the Username field in the Configuration Details section.

– Launch Microsoft SQL Server Management Studio(SSMS). Then Connect to Server dialog box appears in the Server section “select Database Engine”. Now provide the server name of the DB instance then a comma(,) and port number. Example: EndPoint,Port

– Now choose SQL Server as authentication type as this is the only authentication method supported in AmazonDRS. Provide the user name and password and then click connect and you should be connected successfully, unless there are any port or firewall issues. Open a new query window and run few sample queries to make sure you can run queries.

Some of the known issues which you may face while trying to connect to AmazonRDS from SQL Server Management Studio are related to to your local firewall and the IP addresses you authorized to access your DB instance in the instance’s security group are not in sync. If you cannot send out or receive communications over the port you specified when you created the DB instance, you will not be able to connect to the DB instance. Check with your network administrator to determine if the port you specified for your DB instance is allowed to be used for inbound and outbound communication.or newly created DB instances, you must wait for the DB instance status to be “Available” before you can connect to the instance. Depending on the size of your DB instance, it can take up to 20 minutes before the instance is available.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2012
SQL Server 2008 R2

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

Tools to Move Database O-Premise to Amazon RDS or SQL Azure

SQLServerF1

With growing popularity of cloud technologies like Amazon RDS and SQLAzure, there has been lot of interest about understanding these technologies. These cloud solutions are cost effective but are limited on many aspects, one of which is moving data or databases between on-premise SQL Server instance to Amazon RDS and SQLAzure.

Mostly DBAs use backup/restore method to move or migrate databases/data from one server to another server or between SQL instances, but when it comes to Amazon RDS and SQLAzure, Restore is not supported as they do not provide file system level access, so this method is ruled out. Then what other methods are available for us to move data from on-premise SQL Server database to database on Amazon RDS and SQLAzure.

Below are some of the options which are available to move data from on-premise SQL Server database to database on Amazon RDS and SQLAzure.

Generate Scripts – Script create database, and its objects like table schemas, views, Stored Procedures, triggers, users, database roles and permissions, etc. Note that SQL Server Logins need to be created before hand to be able to map the database users to logins. This method can also be used to transfer data, but that will create huge file and can be difficult in writing to and reading from the file and makes things complicated, so better to use this method to create empty database with schemas only.

Import/Export Wizard – SQL Server Management Studion has buit-in tool which is Import/Export wizard which can be used to transfer schema and data. This creates a SSIS package to transfer the data and mostly is easy to create and implement. However there can be some issues with Identity columns, etc, so need to use it carefully and choose proper options.

BCP – For users who are comfortable with command line can opt for BCP which can be used to export data to dat file and then import that data into Amazon RDS or SQLAzure.

Sample commands:

For moving data from on-premise to dat file
BCP.exe “[HR].[dbo].[Emp]” out “C:\AmazonRDS\BCPData\dbo.Emp.dat” -E -n -C RAW -S ServrName\SQLInstName -T

For moving data from dat file to Amazon RDS
BCP.exe “[HR].[dbo].[Emp]” in “C:\AmazonRDS\BCPData\dbo.Emp.dat” -E -n -C RAW -S AmazonRDSConn -U AmazonRDSAdminUser

SQL Database Migration Wizard – Users who are comfortable using GUI tool to take care of data transfer can use SQL Database Migration Wizard which is available in CODEPLEX, which is simple to use. This can be used for both AmazonRDS and SQLAzure.

If you are confused on which tool or which of these methods to choose from, then you may ask yourself questions like do we need to move the data once and will never going to move again and if you prefer GUI method in which case you can using GUI option using SQL Database Migration Wizard or Import/Export in SSMS. If you may require to transfer data periodically, then you may choose scripts/BCP command and use SQL Agent jobs to run it when ever required.

Hopefully this answers all your questions on how to move data between on-premise SQL Server database and AmazonRDS or SQLAzure.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2008 R2
SQL Server 2012
SQL Server 2014

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

Limitations of Amazon RDS SQL Server 2012

SQLServerF1

Amazon Relational Database Service (Amazon RDS) is a web service that makes it easier to set up, operate, and scale a relational database in the cloud. It provides cost-efficient, resizeable capacity for an industry-standard relational database and manages common database administration tasks. Although Amazon RDS is great for many applications to store its data, but has many limitations where many features cannot be used due to restricted permissions at file system level and on registry and OS level. Some of the important restricted features are mentioned below.

– Only SQL Authentication Logins are allowed. Windows authentication is not supported, so applications are to be changed to only use SQL Server authentication.
– Amazon RDS only provides support for core database engine of SQL Server, but does not include SSRS, SSAS, SSIS, etc. If application requires these services, then they can be implemented on on premise server and can access data from Amazon RDS.
– Maintenance plans are not supported, so we would need to use SQL Scripts to implement the maintenance tasks like backups, Index and statistics maintenance, Integrity checks, etc. There are already many of these scripts available like Ola Hellengren scripts. Using scripts also provides flexibility of dealing with these maintenance tasks.

– Linked Server access is limited and only can be configure and used from Amazon RDS to outside SQL Server instances over internet or other Amazon RDS instances.
– SQL Agent role is limited, which causes issues where one user with SQL Agent role cannot see jobs created by another user with SQL Agent role. So workaround is to use only one account for job management.
– In Amazon RDS, during the initial creation of instance, we choose the storage and this storage cannot be changed later. There are no workarounds and will need to create new instance with required storage design and then have to migrate data from old instance to new instance.
– Replication can be setup, but is is limited. We can only configure Amazon RDS instance as a subscriber. We cannot use Amazon RDS instance as publisher/distributor. We cannot use pull subscription too.

Some of the other features which are not supported by Amazon RDS SQL Server 2012 or lower include below.

Database Mail
Service Broker
Database Log Shipping
Change Data Capture (CDC) – Consider using Change Tracking as an alternative to CDC.
Additional T-SQL endpoints
Performance Data Collector
Distribution Transaction Coordinator (MSDTC)
WCF Data Services
FILESTREAM support
Policy-Based Management
SQL Server Audit
BULK INSERT and OPENROWSET(BULK…) features. These must be run from client-based server storage.
Data Quality Services
Instant file initialization
Always On (2012 Enterprise Edition)
File tables
Server level triggers

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2008 R2
SQL Server 2012
SQL Server 2014

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 
1 2