Backup and Restore with Cloud services (Windows Azure Blob Storage Service)

As DBAs, we have the responsibility to backup databases on a regular basis, but we also have to ensure that backups are stored securely and safely, so databases can be restored when needed.  With the current method it is sometimes difficult to control that these backup files are readily accessible when needed.  I heard that SQL Server 2012 now supports backups directly to Windows Azure Blob Storage and restores can also be done directly from Windows Azure Blob Storage.  Can you tell me more about this new feature and advantages of using it over traditional backup options? For more information click here.

Getting started with SQL Data Sync

Windows Azure SQL Database has a feature called SQL Data Sync which synchronizes data across multiple SQL Server and Windows Azure SQL Database instances. SQL Data Sync is a cloud-based data synchronization service built on Microsoft Sync Framework technologies. It provides single direction as well as bi-directional data synchronization and data management capabilities allowing data to be easily shared across Windows Azure SQL Databases across multiple data centers or between on-premises SQL Server databases and Windows Azure SQL databases. For more information refer to below articles:

Understanding SQL Data Sync for SQL Server

Getting started with SQL Data Sync

Column Level Encryption in SQL Server

In my last article, Transparent Data Encryption (TDE) in SQL Server I talked about enabling encryption at the entire database level and in this article I am going to further discuss and demonstrate a more granular level or each individual cell or column level encryption in detail and how it differs from Transparent Data Encryption (TDE). For more information click here.

Transparent Data Encryption (TDE) in SQL Server

Encryption brings data into a state that cannot be interpreted by anyone who does not have access to the decryption key, password, or certificates. Though encryption does not restrict the access to the data, it ensures that if data loss happens, then in that case data is useless to the person who does not have access to the decryption key/password/certificates. Though when you use encryption, there should be a maintenance strategy for passwords, keys, and certificates. 

To meet the demands of regulatory compliance and corporate data security standards, SQL Server allows you to enable encryption at column/cell level or on the database level. You can even use file level encryption provided by Windows for database files.

Though there are several ways/levels to implement encryption in SQL Server, I am going to focus on Transparent Data Encryption (TDE) in this article, which was introduced in SQL Server 2008 and available in later releases. For more information click here.

Getting Started with Microsoft Power BI for Office 365

Microsoft Excel is one of the most widely used tools across the globe. Microsoft empowers Excel users to create Business Intelligence reports quickly in Excel itself with Power BI. Power BI is a familiar, intuitive and cloud based self-service BI (Business Intelligence) solution for all your data needs in your very own Excel, which users have been using for decades. It includes different tools for data discovery, analysis and visualization. Furthermore, Power BI integrates with Office 365 to share, collaborate and much more. For more details click here.

Managing SQL Server Services with PowerShell

PowerShell provides a command-line shell and scripting language (built in the .NET Framework) especially designed for administrative task automation and configuration management. PowerShell includes commands (called cmdlets) to administer SQL Server along with having cmdlets for administering other Microsoft server products. This gives administrators a common scripting language across servers’ platforms. For more details click here.

Getting Starting with Change Data Capture (CDC) in SQL Server

Prior to SQL Server 2008 there was no in-built support to identify changed data set for incrementally pulling data from a source table and hence we had to write our own custom logic (for example by adding Last Created Date or Last Modified Date columns in the source table and updating it accordingly or by some other means) so that changed data sets can be identified for incremental data pull. Starting with SQL Server 2008 we have two different in-built mechanisms (please note, you don’t need to write code for leveraging these features though you just need to enable it accordingly as per your need) to identify DML changes (INSERT, UPDATE, DELTE) happening at the source table so that only changed data sets can be considered for data pull from the source table and to load into the data warehouse called Change Data Capture (CDC) and Change Tracking (CT). Please refer this article to learn more about Change Data Capture (CDC).

Part 1

Part 2