Backup is the most important case for database administration because it provides business continuity solutions for high availability and disaster recovery. For this reason, Azure SQL database (PaaS: platform as a service) can make a backup automatically and restore it at a point in time. However, the retention period of backup files changes according to the service tiers.
Azure SQL offers different types of business continuity solutions. One of these solutions is Geo-Replication that provides an asynchronous database copy. You can store this copy in the same or different data center locations (regions). There can be four readable database copies. In the documentation of Microsoft notes, the recovery point objective (RPO is the maximum acceptable amount of data loss measured in time) is less than 5 seconds. If we want to automate and make (users will not affect) failover mechanism transparent, we have to create the auto-failover group.
SQL Server 2017 now is considered as a hybrid database enterprise solution as it expands its market and is ported to other operating system platforms. It also includes mainstream support for Linux machines. The Cloud makes the life of administrator much easier, now it’s no longer daunting task to configure the SQL Server instance. The easiest way to explore SQL Server on Linux is to provision a virtual machine through Microsoft Azure portal – portal.azure.com. The Linux azure virtual machine will come pre-configured with Linux and SQL Server 2017.
The most important and challenging responsibility of a database administrator is monitoring performance metrics. Because monitoring performance and troubleshooting performance issues are considered to be difficult. For this reason, we need diagnostic and monitoring tools to measure performance counters and metrics. For Azure SQL there is a tool which is named SQL Analytics. With this tool, we can measure and monitor Azure SQL databases and elastic pools. At the same time, we can create alerts for notifications. SQL Analytics offers performance metrics in graphical form. In this article, we will learn how to enable Azure SQL Analytics. Read More
Microsoft has recently announced an incredible new feature – automatic tuning in Azure SQL Database. To be honest, I am thoroughly impressed with this feature because Microsoft engineers have sophisticatedly used artificial intelligence in SQL Azure performance tuning. The aim is to monitor Azure SQL database and send these observations to the built-in intelligence service that generates some recommendations. They can be applied at offpeak times. This feature has also simplified the work of database administrators; they don’t have to worry about SQL Azure database performance now.
Though Microsoft Dynamics 365 does not offer any built-in feature to export the CRM data to external portals so far, there is a simple way to reach there. If we create a web API as an intermediate service using Azure Cloud Services, it can easily export the data to external portals via FTP.
The process of configuring the Cloud Service and Storage in order to export CRM data to an external portal is described below.
In today’s world, it is not enough to simply analyze data, create reports or develop business intelligence projects. To discover the power of data, we have to modify data on machine learning models and to predict future.
In this article, we will discuss one of the simplest methods, a linear regression, that we are going to modify statically in Azure Machine Learning.
Azure is growing every day. Microsoft created Azure, which is a Cloud Computing service released on 2010.
According to Microsoft, 80% of the fortune 500 companies are using Azure. Also, 40% of the Azure Revenue comes from Startups and independent software vendors. 33% of the Azure Virtual Machines are using Linux. Microsoft expects to earn $20 billion in 2018.
That is why companies are migrating part of the data to Azure and sometimes all the data.
Azure Data Lake is a special storage to analyze Big Data in parallel in Azure. It is optimized for analytics. You can store Social network data, emails, documents, sensor information, geographical information and more.
As a rule, impersonal information is stored in a public cloud, and the personalized part – in a private cloud. The question thus arises – how to combine both parts to return a single result at a user’s request? Suppose there is a table of customers divided vertically. The depersonalized columns were included in the table located in Windows Azure SQL Database, and columns with sensitive information (e.g., full name) remained in the local SQL Server. Both tables must be linked by the CustomerID key. Because they are located in different databases on different servers, the JOIN statement will not work. As a possible solution, we have considered the scenario, when the linkage was implemented on the local SQL Server. It served as a kind of entry point for the applications, and the cloud-based SQL Server was set up on it as a linked server. In this article, we will consider the case when both, the local and cloud servers, are equal in terms of the application, and the data merging occurs directly in it, i.e. at the business logic level.
A hybrid cloud is a fairly attractive model when implementing cloud computing in enterprise information systems since this approach combines the advantages of public and private clouds. On the one hand, it is possible to flexibly attract external resources when needed and reduce infrastructure costs. On the other hand, full control over data and applications that the enterprise does not want to outsource remains. However, in such a scenario, we inevitably face the task of integrating data from various sources. Suppose there is a table with customers, which is vertically divided into two parts. The depersonalized part was allocated in a public cloud, and the information personalizing the customers remained in a local database. For holistic processing inside the application, you need to combine both parts by CustomerID. There are various ways to do this. Conventionally, they can be divided into two large categories: data aggregation at the on-premise database server level which, in this case, will be a single sign on for accessing local and remote data, and data aggregation within the business logic. This article will consider the first approach.