What is the main difference between SQL SERVER and SQL AZURE, What is the advantage of SQL Azure
On this article you will find how they compare on topics like features, upgrades, limitations, TCO, business continuity, licensing, performance, security, data transfer and costs. SQL Azure has now more security features than the article show like row-level security, dynamic data masking, auditing, encryption, threat detection, and SQL Vulnerability Assessment as you can read here.
About the Transact-SQL differences of Azure SQL Database compared with SQL Server you will find them here. Some of the most important differences are you cannot rely db_id(), you cannot use DBCC DROPCLEANBUFFERS, linked servers are not available, cross database queries are allowed via elastic queries, some system stored procedures not supported, USE is not supported, four-part names not supported.
Related
Having the older application that joins SQL tables from different databases like this:
SELECT a.value, b.value
FROM databaseA.dbo.tableA AS a
JOIN databaseB.dbo.tableB AS b
ON a.thekey == b.thekey
Being 3rd party, we have to accept the decision of the main implementor for the customer to use the license Azure SQL SAAS (Software As A Service; I am new to that, sorry if some terms are incorrect).
Is it possible to have databaseA and databaseB (that part is possible, checked through SSMS) in the Azure SQL and do the same JOIN (that part is unknown to me)?
I tried, but it failed. I do not know if something more have to be done to make the other database visible from each of the databases, or if it is not possible at all.
If it is not possible, what is the recommended technique to replace the old SQL code?
As you comment said: "I understand that it is different than working within one physical SQL Server. On the other hand, the different servers is probably related to possible replication. Is that correct? ", yes, you're right.
For Azure SQL database(PSSA), we only can use the elastic query to achieve the cross database query:
The elastic query feature (in preview) enables you to run a
Transact-SQL query that spans multiple databases in Azure SQL
Database. It allows you to perform cross-database queries to access
remote tables, and to connect Microsoft and third-party tools (Excel,
Power BI, Tableau, etc.) to query across data tiers with multiple
databases.
Note:
Make sure the primary database have the permission to access the remote databases. Add the the client IP to their database firewall. The remote database can be in different Azure SQL Server.
If you are using Azure SQL managed instance and Azure SQL Server on Azure VM, you can run this across query like on-premise SQL Server.
I read in a few places that SQL Azure data is automatically replicated and the Azure platform provides redundant copies of the data, Therefore SQL Server high availability features such as database mirroring and failover cluster aren't needed.
Has anyone got a chance to investigate deeper into this? Are all those availability enhancements really not needed in Azure? Thanks!
To clarify, I'm talking about SQL as a service and not a VM hosted SQL.
The SQL Database service (database-as-a-service) is a multi-tenant database service, and your databases are triple-replicated within the data center, providing durable storage. The service itself, being large-scale, provides high availability (since there are many VMs running the service itself, along with replicated data). Nothing is needed in terms of mirroring or failover clusters. Having said that: If, say, your particular database became unavailable for a period of time, you'll need to consider how you'll handle that situation (perhaps sync'ing to another SQL Database, maybe even in another data center).
If you go with SQL Database (DBaaS), you'll still need to work out your backup strategy, and possibly syncing with another DC (or on-premises database server) for DR purposes.
More info on SQL Database fault tolerance is here.
Your desired detail is probably contained in this MSDN article of Business Continuity and Azure SQL Database (see: http://msdn.microsoft.com/en-us/library/windowsazure/hh852669.aspx). At the most basic level Azure SQL Database will keep three replicas of your database - one primary and two secondary.
While this helps with BCP / DR scenarios you may also wish to investigate ways to backup your database so you have point-in-time restore capabilities. More information on backup / restore can be found here: http://msdn.microsoft.com/en-us/library/windowsazure/jj650016.aspx
I'd like to ask if there exist any sharding mechanism (like SQL Azure Federations in Cloud) but in SQL Server 2012 .
I've searched a lot but I couldn't find any appropriate solution that resembles Federations. There is AlwaysOn but it's not the same.
Thanks
No, this feature is not in the boxed product in SQL Server 2012. There are many ways to scale reads but merge replication and distributed partitioned views seem to still be the only viable out-of-the-box solutions for scaling writes. Note that the latter doesn't seem to be officially documented separately in SQL Server 2012 - it has all been condensed into the CREATE VIEW topic.
I know in Sql Server, Tables per database "Limited by number of objects in a database", "Database objects include objects such as tables, views, stored procedures, user-defined functions, triggers, rules, defaults, and constraints. The sum of the number of all objects in a database cannot exceed 2,147,483,647."
My question is, whats the max number for the tables I can create in one Sql Azure Databse?
Thanks
Remus is right!
And if you are on a study, better look for size limits, because the current maximum size of an SQL Azure database is 50 GB. Which means that if your database is larger than that, you'll have to wait for new bigger limits to become available. And this is defenitely something that is not changeble via a support ticket.
Other than that you can quickly check your database for SQL Azure compatability using the SQL Azure Migration Wizard from CodePlex - an easy to use SQL Server <-> SQL Azure migration tool.
If you find yourself asking this question, then your plan is flawed. No sane design will need 2 billion objects in a database, or anything close to that.
The official Guidelines and Limitation document mentions some of the limits supported (eg. 150 databases per server). The limit you are asking for is not documented.
I've currently got a "Web" edition SQL Azure server with on database on it. I want to put another database on there but am unsure how the costing works. Will I need to pay the £9.99 per database or database server?
Does it make more sense just to set up a couple of different schemas in my existing database to try and reduce costs?
You pay per database. Creating schemas may make sense if cost is your concern. I have seen this done multiple times. However keep in mind that a few SQL Server/Azure features are schema independent. For example user-defined statistics and roles are schema independent. So as long as you don't use these features you should be good with a schema-based separation.