I've deployed the Sitecore on to Azure CD by using Sitecore Azure 3.0.0.
However, I'm not getting any analytics data until I manually update the "analytics" connection string to sql azure.
If anyone has already configured above, could you help me with queries below:
Is manual connection string the best solution? Or, am I missing any configuration setting for sitecore azure deploy.
Is it possible to Sync SQL Azure analytics to on-premise analytics db? We need this for disaster recovery i.e. to deploy all web,core,analytics to different data centre in event of disaster.
Does DMS slow down the performance of Sitecore CD?
Thanks.
You can add your "analytics" connection string to the connection string patch file defined in your Sitecore Azure config. Do this via the following steps:
Navigate to /sitecore/system/modules/Azure/[Environment]/[Region]/[Farm]/[Role]/[Deployment]
In the deployment item (e.g. Staging, Production), you should see a field named "Connection Strings Patch".
Scroll down in that field until you see the connection strings for the "core", "master", and "web" databases.
Add a connection string element for your "analytics" database. Be sure to use the connection string for the deployment item you're editing, i.e. use your Analytics staging connection string for the Staging item, production connection string for the Production item.
It is not recommended to use Azure SQL Data Sync for backup/disaster recovery (this recommendation is not specific to Sitecore). It is recommended to use a combination of Azure SQL database copying and then Azure SQL database export.
Also, Azure SQL Data Sync has limitations regarding the database schemas supported. SQL Data Sync is unable to synchronize any table that does not have a Primary Key (the Sitecore Analytics database has a few tables without primary keys).
Also, SQL Data Sync synchronizes only data but not stored procedures and triggers (the Sitecore Analytics database does have stored procedures).
Lastly, as your Analytics database grows, a sync operation is likely to take a significant amount of time to complete, whereas a copy operation will still take some time but likely not as much and will place less of a burden on your SQL server.
This MSDN article provides and overview of the copy/export process: http://msdn.microsoft.com/en-US/library/hh852669.aspx#adr3
This MSDN article provides details on how to copy Azure SQL databases: http://msdn.microsoft.com/library/ff951631.aspx
Yes, Sitecore content delivery server performance is impacted when DMS is enabled. To what extent largely depends on how you're using DMS (e.g. personalization, MV testing, engagement plans) and the amount of traffic your server receives.
Related
I migrated from sql server to Azure db.
While migrating I found a job named syspolicy_purge_history, do I also need to implement it on Azure db?
As I found the syspolicy_purge_history job is targeting msdb, but I could not found msdb on Azure. A guidance will be highly appreciated...
You can implement syspolicy_purge_history job in case of azure database and msdb not available for Azure SQL Data Warehouse in your case its applicable and supported all version of msdb database
Syspolicy purge history is the default job that deletes data that is older than the number of days specified in the HistoryRetentionInDays property of Policy Management. This prevents unnecessary space consumption in the MSDB system database.
For your Reference:
sp_syspolicy_purge_history (Transact-SQL)
Migrate SQL Server to Azure SQL Database
Is it possible for me to insert some data from one database to another in Azure sql?
Let's say I have a trigger in db1 that updates some values in db2.
I read about elastic queries but it seems like they are read-only so they don't solve my problem.
You can't use cross-database in Azure Sql Server because databases can't see eachother physically , you could use elastic pools but they are Read Only.
A solution is to use SQL Managed Instance to upload your instance . This supports cross-database queries but it was expensive.
There was some previous discussion here about doing similar:
C# Azure Function trigger when SQL Database has a new row added without polling
There is also the Azure SQL Bindings for Azure Functions but they are input bindings and not triggers and they're still in preview and limited to C#, JavaScript and Python.
Azure SQL bindings for Azure Functions overview (preview)
There was a new announcement last week after MS Build however for Azure SQL Database External REST Endpoints Integration (hopefully they don't refer to it as ASDEREI) but this is currently in preview under Early Adoption Program (EAP).
Announcing the “Azure SQL Database External REST Endpoints Integration” Early Adoption Program
I would like to know what extra benefits one get by choosing Azure SQL Managed Instance compared to Azure SQL DB PaaS. I know SQL Managed Instance is offered as a vCore based purchasing model only. Apart from this what is the extra add on and benefits that one gets over the other. Any reply would be appreciated.
With Azure SQL Managed Instance, you essentially get a full fledged SQL Server that you can control any way you want, just like you would control a locally configured SQL Server. All the power and access and customization you want.
With, Azure SQL DB PaaS, you are essentially getting a database service, so, you give up a lot of control.
For example, take server collation. With the database service, SQL_Latin1_General_CP1_CI_AS , is all you get. With the Managed Instance, its your server. So, go ahead and select whatever collation you want, just like how you would select the collation at the time of creatoin.
Another issue is with auditing, if that is something that is important to your setup. with SQL Managed Instance, auditing happens at server level, because, you are getting the full database server. With the database service, it only database, because, you are only getting a database.
These are just the main details that I found. more details here at this Azure doc - https://learn.microsoft.com/en-us/azure/azure-sql/database/features-comparison
Of course, Managed is going to cost you more because you are paying for the license of the SQL server too.
Lastly, for me, this is the almost (not the exact same thing) like you running your own File Server on a Windows VM on Azure (Managed Instance) versus, just using Blob Storage. In both cases, you are just trying to store some files, but its how much control you have.
I would say think about Azure SQL DB vs Azure SQL Managed Instance (MI) as
Azure SQL DB = Resources dedicated to individual DBs like a container. They are grouped under a Azure SQL Server but that SQL Server is just for grouping.
Azure SQL MI = Almost same as on-prem SQL Server except you don't have to worry about OS, backups, high availability.
Here is a good comparison.
https://learn.microsoft.com/en-us/azure/azure-sql/database/features-comparison
Hopefully this will help
Azure SQL Database - The usual PaaS way. You have vCore, DTU, and Serverless billing mode. And Elastic pool support.
Azure SQL Managed Instance - Similar as below. When you want to use instance-scoped features of Azure SQL Managed Instance like Service Broker, CLR, SQL Server Agent, and Linked servers. As if you have an SQL Server on premise, Azure is responsible for patching, upgrading version etc.
SQL Server on Azure Virtual Machines - Similar as above. But you are responsible for OS and SQL server upgrade.
Currently, we are mirroring our local SQL server Database with Azure SQL Server Database. For this, we are using Azure Data Management gateway but the problem is we are not able to handle the update or delete scenario. Update and Delete are not reflecting in Azure SQL Server database(Mirror).
Thanks.
What type of activity are you using in your pipeline? I'm assuming a simple copy activity?
My suggestion would be to have a copy activity that lands a clone of the on premises data in the Azure SQL DB first, maybe in a staging schema set of table or something. Then have a second downstream activity that performs a stored procedure execution activity. You can code a MERGE statement or whatever in the procedure to output the data into a separate table.
It sounds like you almost want a secondary node for your SQL Server in Azure. Maybe just use an availability group?! SQL 2014 or higher required on prem though.
You can also take a look at Transactional Replication to Azure SQL database, with transactional replication, Azure SQL database acts as a subscriber, update/delete changes you made in on-premises SQL Server database will be reflected in Azure SQL database.
I would like to transfer my existing SQL Azure location to other one, but I think there is no functionality right now to do so on the management portal of Azure.
I just googled it and found one link http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e6c961cc-5eea-4f07-82c9-a8805d367b05 that says I need to use the data sync option in Azure's portal but I don't have that feature enabled in my Azure portal.
Also if I do use that option, is there any charge for it? Finally, are there any other option that is possible for moving the SQL Azure location?
To Move an Existing SQL Server Database to a New Region on Azure Assuming There Are No Blob Containers Associated With the Database. For further reference see:
https://azure.microsoft.com/en-us/blog/migrating-azure-services-to-new-regions/
Upgrade the database, if necessary, to one of the Premium pricing tiers
Add geo-replication to the existing database. You can choose what region to have the backup of the existing database. Create a new Database server in the target region of your choice. I suggest provisioning that new database server with the same admin username and password as the existing sql database. When creating the secondary database, I suggest making the Secondary type “Readable” as it will allow you the ability to check that all data and schemas were replicated correctly.
Allow the two databases time to sync. Rule of thumb according from Microsoft AzureCAT is: 3 * (5 minutes + database size / 150 MB/minute)
Configure the Firewall settings of the secondary database to allow the necessary IP addresses to access the database
Temporarily shut down whatever users or applications are accessing the existing database.
From the Azure portal select the existing database and change its geo-replication role from primary to secondary.
Run any ddl scripts that rely on the masterdb such as ddl scripts to recreate users and user profiles
Change the connection strings of any applications to point to the new database.
Users and applications can now connect to the new Database
At your discretion you can remove the old database as a backup and add any new regions as backup.
In terms of charges there will be charges for upgrading the old database if it isn't already a premium database. There will also be charges for creating the geo-replicated database. However, those charges can be limited to a day to a few days worth of fees (depending on how long geo-replication takes). Once the new database is up and running, delete the old database as soon as possible to limit additional fees. Finally, if you upgraded the service level of the old database to a premium tier to facilitate the geo-replication, you will want to downgrade the new database to the original service level of the old database to also limit fees.
I think you can use new Import/Export bacpac feature. I have used it to move databases between accounts and can't see why it wouldn't also work between regions.
See how here
If you are able to stop writes to the DB for a time then you can use the Copy feature on the Azure Portal.
Create a new SQL Server in the region of your choosing.
Add your service(s) IP addresses to the new SQL Server firewall.
Stop writes to the origin database.
Open the origin database in the Azure Portal and click Copy at the top of the blade.
Choose your new SQL server located in the destination region.
Wait for the copy to complete.
Update your service(s) to point to the destination DB.
Enable DB writes.
Verify everything is working.
Delete origin database (and server if it was the only DB on the server).
I wouldn't use DataSynch because it creates many objects in your database to perform synchronization (it's an invasive solution). You can indeed try the Import/Export feature; that should work fine. You can also download a trial version of the Enzo backup tool, which comes with a 30-day free trial: http://www.bluesyntax.net/backup.aspx. [disclaimer: I am the author of this tool]
Regarding the pricing question, you may be charged for data being extracted out of the database. Moving data "in" SQL Azure is free of charge for now. If you are transferring the data to a different data center, you will be charged for extracting the data. It's 15 cents per GB in the US and Europe, and 20 cents in Asia. Here are the pricing details: http://www.microsoft.com/windowsazure/pricing/
Keep in mind that a database that requires 4GB of storage doesn't mean you have 4GB of data. Sometimes indexes can take a lot of space. To estimate the size of the data you will need to transfer you can either drop your indexes (and wait a little for the database size to shrink; the database size should be roughly equal to your data transfer needs) or you can calculate the size of your tables by running a command. Here is a link to an article that shows how to do something similar (look at the second command with is a SELECT statement; just run it for all the tables): http://www.sqldocumentor.com/table-size-in-sql-server-find-rows-and-disk-space-usage
Azure has released a new tool called Azure Resource Mover.
Resource mover can for now handle these resources:
Azure VMs and associated disks
NICs
Availability sets
Azure virtual networks
Public IP addresses
Network security groups (NSGs)
Internal and public load balancers
Azure SQL databases and elastic pools
https://learn.microsoft.com/en-us/azure/resource-mover/move-region-within-resource-group
Azure SQL Server is not supported yet but Azure has a complete guide for this anyway:
https://learn.microsoft.com/en-us/azure/resource-mover/tutorial-move-region-sql#move-the-sql-server