Does Azure Search have feature parity between what is available in the commercial cloud vs. what is available in Azure Government? If not, do we have any pointers to what the differences are?
Related
Do you know anything about Data Quality Services? When it will be introduced in Microsoft Azure? Or maybe there is some services with same functions and possibilities?
If you really want Data Quality Services (DQS) there is nothing to stop you provisioning some virtual machines (VMs) and installing SQL Server and DQS on them, ie as Infrastructure as a Service (IaaS). See here for DQS installation instructions:
https://learn.microsoft.com/en-us/sql/data-quality-services/install-windows/install-data-quality-services?view=sql-server-ver15
As you can see here there are a good amount of people interested on that feature to come to SQL Azure but there is no official response. Please vote on that URL to grab attention from the Azure SQL Database team about that topic.
Meanwhile you can install SQL Server and DQS on an Azure VMm but you may also consider third-party products available on Azure Marketplace (here).
Looking to help a customer migrate their Sharepoint to Azure along with a lot of their other virtual workloads. I'd rather not use the Office 365 Sharepoint product. Rather host Sharepoint on IaaS and either the supporting SQL Server on a BYOL/IaaS VM or use the managed Azure SQL (if possible). I can't seem to locate that certification information and would also be interested in anyone's experience.
Hosting SharePoint databases on SQL Azure is not officially supported but this Microsoft blog post shows it is possible. It is not supported because SQL Azure cannot guarantee 1 ms latency required by SharePoint as explained on the article. If you don’t like SharePoint online then you should install all SharePoint servers on Azure VMs.
Hope this helps.
Regards,
Alberto Morillo
This is great question (I have no idea why did he get a negative points), and I would like to give an updated answer (for today) even so it is an old thread from a year ago, since we have new features today. It is important to mention that the answer today is probably YES (you can use it for most cases), although it is still not officially documented/supported.
First, let me repeat what I said that officially it is still not supported, but probably only because no one documented it yet and you should test it.
In the blog that Alberto mentioned (it is from 2015) Sam Betts says that you should make sure the region of the Azure SQL Database is the same as your SharePoint servers region in order to avoid latency. In 2015 that was the only recommendation, since you had no control over the vNet of your Azure SQL Database.
On February 2018 Microsoft announced the general availability of Virtual Network (VNet) Service Endpoints for Azure SQL Database in all Azure regions. In addition we have a new deployment option for Azure SQL Databases As A Service today named "Managed Instance", which also allows us to control the vNet and to create for example Virtual Machines (and other elements) which use the same vNet.
If you want to use Azure SQL (PaaS) for SharePoint hosted in Microsoft Azure, you should make sure that you are working under the same region and under the same vNet. Without fully familiar with your system I cannot give direct absolute answer like YES or NO, and You should test the system but probably for most cases it should fit.
I'm exploring whether to use Azure SQL Database or SQL Server in Virtual Machine. What are the pros and cons each of them?
Thank You.
Well...SQL Azure is PaaS, and Sql Server in VM is IaaS. Just to highlight some differences.
Control & Features - You got a greater control and features in IaaS where else in PaaS you got to stick with the features they have.
Redundancy & Backup - By default, SQL Azure comes with 3 copies of redundancy and you can enable geo-replication to nearest datacenter too. Backup is automatically done for 7 days and onwards depending on the pricing tier.
Cost & Ownership - Basic DB in SQL Azure cost you USD5, however in VM, you can host as many db possible albeit more expensive to rent a single VM.
Check this link out to find out more details
My company's product has a big relational database storage(around 20 TB) and we want to move all or some part of our database. Now I am a bit confused regarding which cloud SQL service will be suitable for me. I have read that some cloud storage only provides specific SQLs like MySQL ... which I cannot afford, the reason is that here we have lots of Transact-SQL scripts on our MSSQL server, which periodically updates the data.
So what should be my basic approach to achieve that, How can I compare between various cloud-based relational database storage like Google Cloud SQL, Azure SQL and Amazon RDS?
If your existing SQL server is Microsoft SQL Server then it probably makes the most sense to use a Microsoft SQL server offering in a cloud environment. That will help minimize any sorts of compatibility issues and also minimize the need to learn a new SQL server environment.
Amazon's RDS service lets you choose between various versions of MySQL, Postgres, Oracle, and Microsoft SQL Server. With regards to Microsoft SQL Server, Amazon offers an express edition, as well as SE and EE versions. As far as licensing goes, they offer both "bring your own" as well as pay-by-usage licenses. More information on the license details can be found in their RDS documentation. They also have a usage calculator that lets you estimate what your monthly costs will be based on the license you use, the size of the instance, etc.
Since Azure SQL is a Microsoft product I would hope that it's compatible with Microsoft SQL Server but I have never used it so I honestly have no idea if there are any compatibility issues. Microsoft also has some basic pricing information available for Azure SQL so you can work out an estimate of your costs if you go with them.
If you're concerned about any scripts working properly on one of the cloud platforms then I'd suggest creating a small test database that you can thoroughly test those scripts with. Upload that test database to the different clouds and test the scripts there to ensure they function properly. Amazon offers a very light-weight RDS instance for free so you can do basic testing without it costing you anything. Perhaps Azure offers something similar. Even if they don't or the free RDS instance isn't powerful enough for your testing needs, spinning up an instance for a day or two to run these sorts of tests shouldn't cost you very much.
I have a client that runs a small business. They need a custom database solution and I'm looking into various options. My experience is limited to .NET using local SQL Servers (no ASP.NET), however, this client is non-technical and would benefit from being able to outsource the DBA tasks. I'm a complete Azure noob, I just scanned the tutorials and they all appear targeted at developing MVC ASP solutions. The client doesn't need a browser based solution. A fat desktop client used from different geographical offices would be the least expensive option I can deliver. I'm just trying to save some time going through all the tutorials and docs only to find out that this isn't what SQL Azure is intended to do. In effect my questions boil down to:
Can I develop a C#/.NET WPF desktop application using Entity Framework 4 and have it hit SQL Azure instead of a local SQL Server?
Are there any known gotchas with EF4 and SQL Azure?
Are there other hidden development costs/complications in using SQL-Azure instead of a local SQL Server.
Is the basic tool support the same? One specific example I can think of; do I get a SQL profiler tool for troubleshooting?
The final question is security related and I'm not sophisticated enough to ask a good question, but is hitting a SQL Azure db this way considered a security no no?
Yes, you can, but a more suitable approach would be to use WCF Data Services or another form of web services (asmx or WCF) as a services layer for your application. I like this approach for line of business applications. I hate web apps for line of business and by using a services connected WPF desktop application, you get the benefits of running in the cloud and having a cloud offering without the necessity to be HTML based.
SQL Azure has full support for EF these days. In the past there were some issues, but I have not encountered any these days.
In terms of development costs and complications - the Azure desktop hosted environment is a bit of a PITA from a development perspective, but I haven't had major problems. You lose the ability to share a local DEV SQL Server unless you use a hosted instance....of course there's a development cost in that because you have to pay for usage.
Good point! SQL Azure does not provide SQL Profiler support at present. I personally use the built in EF tracing support for this functionality.
Exposing a SQL Azure DB directly isn't a good idea from a security perspective. That's why I suggest hitting a WCF Data Services (or other web services) endpoint in point 1.
You can develop a desktop or on-premise application that uses SQL Azure for your database.
You need to take the standard Azure precautions - assume that connection failures will occur and ensure that your application has retry logic to restore operation. Also note that SQL Azure will terminate any operations that take longer than a minute, to preserve the service for other users. If you have lots of data and some nasty queries, that might be relevant.
EF works fine with SQL Azure. There are some limitations to SQL Azure, itself, which you can read about from the documentation on Microsoft's web site. If you design you database for Azure, it'll work fine on SQL Server or SQL Express (but not necessarily the other way around).
In addition to the monthly charge for the database, you will pay for data that leaves the data centre. Design your application carefully to minimise the amount of data that is retrieved from the database. You no longer have to pay for data going into the data centre, which helps.
You can still use SQL Management Studio and Data Connections within Visual Studio. No SQL Profiler, though. There are a few irritating things you can't do with Management Studio, but nothing insurmountable.
You will have to open up firewall rules for access to the database, but hopefully, they'll be limited. Authentication is by SQL Server credentials, not integrated authentication.
I wouldn't tend to do it this way, but it works.