Comments
2 comments
-
1. If you're running in a vCore model you can just use the requirements posted here:
https://documentation.red-gate.com/sm11/installation-and-setup/planning-the-sql-monitor-infrastructure-and-installation/sql-monitor-database-requirements
If your on-prem setup uses 1 core per 5 SQL servers (hypothetical example) you can just extrapolate this to the cloud.
For the DTU model you can find 'converters' to a core/dtu online.
A good thing, you can scale Azure SQL Database up or down, so you can play around to find the correct infrastructure for your requirements.
2. If you dive in the data I'm sure you'll find a way to export the data and import on the new location. But this will be custom and very time consuming.
I would just disable the monitoring on the current location (saving you the license) and start the monitoring on the new base monitor.
That way for a brief moment of time (depending on your retention settings) you can use the new base monitor for current issues and the old base monitor for history.
If you disable the monitoring for a server, you keep any data history. -
Hi @...
1. We don't have recommendations/minimum specs for Azure SQL DB as the repository. I will say to ensure the storage tier related to it has sufficient throughput to allow it to keep up with the amount of data being sampled/inserted and served to the web UI by the Base Monitor service, though what that is, depends on how many entities you are monitoring and how busy they are.
2. There is not a built-in export option and I would suggest to raise a Redgate Monitor Uservoice suggestion here https://sqlmonitor.uservoice.com/forums/91743-suggestions/filters/top. You can also remove and not tick the box to delete the entity data, which will keep the historical data until it is purged, or as stated above, suspend monitoring and ensure a license is not being consumed by the entity on the Configuration > Monitored servers page.
Kind regards,
Alex
Add comment
Please sign in to leave a comment.
My questions are:
Matt.