Currently I am hosting my online application on an Azure VM. This is a pretty standard Umbraco website with around 300 visitors per day, nothing special here.
Details of Azure VM:
- Basic A3
- 4 cores
- 7 GB Memory
In the current situation MsSQL is installed on the VM itself and this is working fine, but I am not a great expert in maintenance. A solution I found is migrating the SQL database to SQL Azure.
Looking at my current website I decided to do this and I migrated the database to SQL Azure:
- S3 Standard
- 100 DTU
- 250GB
After the migration I switched the connection string with the connection string that was provided in the Azure portal. When I reloaded my website the loading time was suddenly three times slower.
For now I switched it back to the local SQL Database, but I am wondering if it is a normal situation that the local SQL is faster then SQL Azure in this case.
I hope someone can answer my question, please let me know if more information is required to answer my question.
Best regards, Martijn
EDIT
The issue is resolved! I found out that the SQL Azure Server that I created was located in a different region then the Azure VM. After I created a new SQL Azure server in the same region the performance issues where fixed.
Good to hear your perf issues are fixed. In general, comparing the performance of a local database versus a PaaS database is not always an apples-to-apples comparison for a number of reasons:
Azure SQL Database is a highly available service (99.99%) that requires synchronous commits to a secondary database. A local database typically is not configured for high availability.
Azure SQL Database provides automatic backup. Depending on your setup, a local database might may or may not be configured for backup.
The affect of network latency on a local database does not exist
The memory and CPU between of a S3 Azure SQL Database and a A3 VM are likely not the same
Related
We are supporting a legacy system for our organisation. In the current scenario, we receive a SQL Server backup (.bak files) from the application vendor on an FTP location. For every weekend on Sunday it is a Full backup and for every other day its the differential one.
On our side, we have a SQL server instance running which has custom stored procedures written and scheduled to check the location every morning and then restore the backups every day. These restored backups are then used by the organisation for internal reporting purposes. There are 100s of other stored procedures written for different reports in different DBs on the same instance.
Since SQL Server 2008 is now out of support and for cost-saving purposes of running on-premise system, my team has been given a task to look into migrating this whole system to Azure SQL database.
My question is what is the most effective way in which we can move this workflow to the cloud? I have an azure trial account set up for me to try but haven't been successful in restoring the .bak files on Azure SQL instance.
Thanks.
You essentially have two options for Azure, either perform a fairly linear Lift and Shift to SQL Server on an Azure VM or go with a more advanced Azure PaaS offering in Azure SQL Database Managed Instance. The specific deployment Azure SQL Database (Single Instance) will not support your current solution requires with regard to the .bak file support, and I have detailed that below. For further details between the difference between Azure SQL Database Single Instance versus Managed Instance, please see: Features comparison: Azure SQL Database and Azure SQL Managed Instance
The second option, is to leverage the Azure Enterprise Ready Analytics Architecture (AERAA) (link) of Azure (PaaS) Analytics services. With Azure SQL Database (PaaS) services, as opposed to on-premise SQL Server or SQL Server on an Azure VM, there is no Integration Runtime or Analysis Services as a bundled service component. These services are separate PaaS offerings and with the help of the linked AERAA blog, you can gain a better understanding of the Azure Analytics services.
The .bak versus .bacpac support dilemma:
Since the main requirement for your solution is support of .bak files, you need to understand where .bak and where .bacpac files are supported. The term Azure SQL Database applies to both a specific deployment option for an Azure SQL database (PaaS) service and as a general term for Azure SQL cloud databases. As for the specific deployment option, Azure SQL Database (Single Instance nor Elastic Pools) will support your scenario with .bak files. This deployment option will support export/import functionality via .bacpac file format. It will not support full/partial restore functionality. The backup/restore functionality although configurable, is only in scope for the specific database hosted by an Azure SQL (logical) Server instance. Basically, you can not restore an external file. You can import, which is always a full copy. So, for that reason, for an Azure PaaS database service you will need Azure SQL Database Managed Instance for .bak file support or deploy an SQL Server VM image to an Azure VM, and migrate your objects via Azure Database Migration Service.
Regards,
Mike
We are trying to evaluate possibility of migrating our in-house SQL DB server to Azure SQL as a PaaS.
Our legacy windows application which is written in VB6 and now running on VB.NET Framework 4.5
Clarifications I need if I migrate only DB server to Azure:
We use both trusted / credential based SQL connection from our desktop application to connect to SQL DB. If we migrate to Azure SQL, will it support trusted connection which should authenticate current organizations NT user?
We have lot of cross DB queries, do we need to face any challenge to use the queries as it is?
Run time we take a DB backup / restore for some business cases. Does this work?
Are there any restrictions on number of admin users on Azure DB?
Probably yes if you sync your local AD with an AAD (See: Use Azure Active Directory Authentication for authentication with SQL Database, Managed Instance, or SQL Data Warehouse)
Azure SQL Database (PaaS) doesn't support cross DB queries by default - you have to setup / use Elastic Query for that.
Yes, you can take a DB backup at runtime and also restore it. There is also a point-in-time restore feature available. See: Learn about automatic SQL Database backups.
I think you can only specify one server administrator (at least within the portal) but I doubt you will reach any limit on db users.
Instead of using the single database SQL Server PaaS service you should also consider using Managed Instance (preview)
You will have to extend your active directory to Azure active directory to keep using trusted connections. You will learn how to do it on this documentation and this one.
On Azure SQL Database you have elastic queries that allow you to run cross database queries. Learn how to create elastic queries here.
You can create bacpacs (export your databases) to Azure Storage or to on-premises location very easy.
You can configure one Server Admin or one Azure Active Directory Admin (it can be a group) for your Azure SQL Server. However, at the database level you can add many database users to the dbmanager role. You can have more information about this topic here.
I have a large database in an AWS instance running SQL Server 2008 on a Windows Server 2008 R2.
The database is constantly changing and writing information, and its size is about ~100GB
I wish to migrate from our Amazon services to Microsoft Azure.
But I cannot afford any lost of information more them for more than 20-30 minutes
I don't mind using the Azure SQL or running a SQL Server under a VM in Azure Cloud, but I must keep the databases live and updated, there are few main tables that information is being added to them constantly
What would be the best way to do so ?
if you are using an AWS instance and not RDS and you are going to an Azure instance and not "Azure SQL Database" you can use log-shipping or something similar to get the downtime down to a few seconds: http://msdn.microsoft.com/en-us/library/ms187103.aspx
The steps you need to take:
Take full backup on AWS
restore full backup without recovery on Azure
take log backup on AWS
restore log backup without recovery on Azure
repeat 3 and 4 until the time it takes is short enough (you probably want to script this out)
take app offline
take another log backup on AWS
restore that log backup WITH recovery on Azure
repoint App to Azure
bring App online again.
3, 4 and 5 is what log-shipping would automate, but you could just write a powershell script too.
I've gotta admit that I'm a Microsoft .NET developer, and I'm not an expert in SQL Server.
I have developed a Windows app, with data stored in my local SQL Server (Express version). I recently purchase a shared hosting service, including a SQL Server. I thought about backing up my local data to remote server: about 5-6 tables from my local SQL Server to remote server, and 1-2 tables from remote to local
What's the best way to do this? DB size is limited to about 5-10MB. The structure of 2 DBs are different, synced tables have same structures. Is there an automatic script I can run from SQL Server Express to do this task every 15 minutes or so?
For initial publishing I’d just go with restoring a backup in the hosting environment. For further synchronization you can try some of the 3rd party tools such as ApexSQL Data Diff or SQL Data Compare or basically any other tool in this category…
I am using Azure VM role. I created a separate VHD (uploaded to page blob) for storing SQL data files (to overcome data persistence issue with VM role). The SharePoint 2010 has been configured on VM. I want to run 2 instances of Azure VM, where I am faining as mounting the data VHD in write mode on 2 instances is not possible. Can anyone help me out in this?
To add to what Joannes said:
A Cloud Drive may be mounted by exactly one writer, but you can make any number of read-only snapshots. This won't help with a scale-out scenario that you're describing, but I just wanted to clarify.
SharePoint 2010 is not a supported configuration in a VM Role currently. There's licensing, compatibility with SQL Azure to consider, scale-out, and potentially other issues. Same goes with installing SQL Server in a VM Role.
Support issues aside, you could look into Azure Connect as a way to reach an on-premise SQL Server instance. This alleviates your need to store SQL Server data files in a Cloud Drive. This will have bandwidth-related performance and cost implications, but it's certainly an option.
CloudDrive is not intended for scaling out. In other words, a blob can be mounted by no more than 1 VM at the same time. This limitation is very unlikely to be lifted in the future, as a single blob is note intended to support scalable writes.