We have two different Azure Accounts with each having a set of databases.
Now, there is one database that we need to access in both the accounts with joins involving local tables (Especially one huge local table).
We tried distributed queries, but the performance dips with joins. We, therefore, want to mirror a table from the other azure account into this account's db so that it becomes a local table and join work faster.
We only need read only access to the mirrored table, the changes need to reflected almost instantaneously though the frequency of updates is not that high.
What is the way of achieving this ?
It seems like you are using Azure SQL. Please mention that your DB is Azure SQL or on any VM using MS SQL.
If it is Azure SQL, you can simply replicate your db with sync tool available in azure.
please follow this link:
https://azure.microsoft.com/en-in/documentation/articles/sql-database-get-started-sql-data-sync/
You can use single way sync so ops will get more faster.
HTH.
Related
Since I initially created an Azure SQL Server database while building an app for a client, they have changed Azure subscriptions. The client wants the database migrated to a new account and eventually deprecate use on the old account when we are done with the new version of the app. In the meantime, they want any updates from the old database duplicated into the new database.
My question is, is there a way to update two databases, one a copy of the other, at the same time on separate Azure accounts?
I've read into active geo-replication but that looks like it can only be done between two databases in the same Azure subscription.
Thanks for the help.
Active geo-replication indeed is only possible inside a subscription, if you are using Azure SQL that wouldn't be possible with it. You could possibly use some kind of replication using on Premise SQL, but that would be pretty hacky. You would want to work with Azure SQL Data Sync.
If you are using a VM with the SQL Server you could create AlwaysOn databases for that purpose.
But if the question is: My question is, is there a way to update two databases, one a copy of the other, at the same time on separate Azure accounts?. You could probably code your application in such a way to write to 2 databases, but again, you would also need to keep track of operations
I have an existing SQL Server database that uses Full Text Search and Semantic search for the UI's primary searching capability. The tables used in the search contain around 1 million rows of data.
I'm looking at using Azure Search to replace this, however my database relies upon the Full Text Enabled tables for it's core functionality. I'd like to use Azure Search for the "searching" but still have my current table structure in place to be able to edit records and display the detail record when something has been found.
My thoughts to implement this is to:
Create the Azure indexes
Push all of the searchable data from the Full Text enabled table in SQL Server to Azure Search
Azure Search to return ID's of documents that match the search criteria
Query the existing database to fetch the rows that contain those ID's to display on the front end
When some data in the existing database changes, schedule an update in Azure Search to ensure the data stays in sync
Is this a good approach? How do hybrid implementations work where your existing data is in an on-prem database but you want to take advantage of Azure Search?
Overall, your approach seems reasonable. A couple of pointers that might be useful:
Azure SQL now has support for Full Text Search, so if moving to Azure SQL is an option for you and you still want to use Azure Search, you can use Azure SQL indexer. Or you can run SQL Server on IaaS VMs and configure the indexer using the instructions here.
With on-prem SQL Server, you might be able to use Azure Data Factory sink for Azure Search to sync data.
I actually just went through this process, almost exactly. Instead of SQL Server, we are using a different backend data store.
Foremost, we wrote an application to sync all existing data. Pretty simple.
For new documents being added, we made the choice to sync to Azure Search synchronously rather than async. We made this choice because we measured excellent performance when adding to and updating the index. 50-200 ms response time and no failures over hundreds of thousands of records. We couldn't justify the additional cost of building and maintaining workers, durable queues, etc. Caveat: Our web service is located in the same Azure region as the Azure Search instance. If your SQL Server is on-prem, you could experience longer latencies.
We ended up storing about 80% of each record in Azure Search. Obviously, the more you store in Azure Search, the less likely you'll have to perform a worst-case serial "double query."
We have a requirement where we will have to move data between different database instance on regular basis. (For e.g. some customers willing to pay more for the better performance). So this is not going to be one off.
The database tables has referential integrity. Is there a way in which this can be done without rewriting sql script (or some other method) every time we migrate customers data?
I came across this How to move data between multiple database's table while maintaining foreign-key relationships/referential integrity?. However it appears that we have write script every time we migrate data (please correct me if I misunderstood the answer on this thread).
Thanks
Edit:
Both servers are using SQL Server 2012 (same version). Its an Azure SQL Server database.
They are not necessarily linked (no firewall between them)
We are only transferring some data, not the whole database. This is only for certain customers who opted pay more.
The schema are exactly same in both databases.
Preyash - please see the documentation on the Split-Merge tool. The Split-Merge tool enables you do move data between databases, as you have described, based on a sharding key (e.g., customer ID). One modification that you will need for your application is to add a shard map (i.e., a database that understand the global state of which customers resides in which databases).
Have a look into Azure Data Sync. It is much more aligned with your requirements. But you may end up in having another SQL Azure DB to maintain a Hub. Azure data Sync follows hub-spoke pattern and will let you do all flexible directional syncs with a few minutes of syncing gap. It is more simple and can set it up very fast without any scripts and all as you wanted.
Hi i am building a window apps retailer pos but was wondering what is the best method to design the database. Should i just use 1 database to store all my clients data?
Meaning to say if i have 100 clients from different businesses using my App, all of their data will be stored in 1 database.
e.g. i will store 1 company column in the user table to indicate which company does the customer or transaction belongs to.
My current practice is i create new database for each business and put it installed into their local machine. (Got to manually install sqlserver + sqlexpress).
Do u think it is more easier for me to design in this way? and i can just put the database online to sql server. Will i be getting any latency ? how bad will it be? I heard Window Azure able to handle this well. In my case i think the speed and data size per business is not really a concern.
Could you advice?
You should definitely look at other alternatives within Azure for storing data, specifically Azure Storage Tables and Blobs.
Utilizing all of the Azure Storage Options with SQL Azure will allow you to choose different data tiers depending on your application's needs and your desired cost structure. Running everything inside of SQL Azure will cost you more in the long run, but it makes a good place to tie together federated data for relational reporting, whereas you can store each tenant's data inside of Azure Tables, using PartitionKeys which keep each client's data separated from the others.
I'm creating a Multi-Tenant application that uses separate databases for each 'client'.
Is it safe to keep all the clients databases on one SQL server? Assuming I give each db its own user account?
Thanks
There was an excellent blog post by Brent Ozar last week on this exact subject.
How To Design Multi-Client Databases
Yes thats basically good idea to manage the tenanats from one sql server(better in terms of resources etc), but you need to create one seperate database for storing the connections strings of other tenant databases, roles etc.
It would be fine with one sql server, if you decide later on to place all the data into cloud. Basically its easy to manage . Also If you want to update any procedure, you can do it easily for all the tenants.
I'd normally use one database per client on the same instance.
From a security perspective, you then have only to deal with logins and users: not permissions per schema or whatever in one big database.
Note that SQL Server will balance resources across all database per instance fairly effectively: not all databases will be in use at the same time so memory etc will be allocated to need. You lose this advantage with multiple instances.