Comments
Sort by recent activity
Hi markkathyc0pley,
There's information about log file location at https://documentation.red-gate.com/display/SBU7/SQL+Backup+log+files
If this doesn't help, please do get in touch with our product support team.
Thanks,
Colin. / comments
Hi markkathyc0pley,
There's information about log file location at https://documentation.red-gate.com/display/SBU7/SQL+Backup+log+files
If this doesn't help, please do get in touch with our product...
Hi mohammad.hafizullah,
There shouldn't be the change in performance that you're experiencing -- please contact product support, they should be able to help you with this.
Best regards,
Colin. / comments
Hi mohammad.hafizullah,
There shouldn't be the change in performance that you're experiencing -- please contact product support, they should be able to help you with this.
Best regards,
Colin.
Hi webrunner,
You can choose to apply either the v3.10 patch, or to upgrade to v4.2, irrespective of your support status. There are some minor performance / data collection implications if you upgrade from v3.x to v4.2, but in exchange you get the features in v4 (eg, wait stats). The implications of either upgrade option are described at http://www.red-gate.com/products/dba/sql-monitor/entrypage/security-vulnerability, if you scroll towards the bottom of the page.
New features in v4 are described in the release notes at http://documentation.red-gate.com/display/SM4/SQL+Monitor+4.0+release+notes.
Hope this helps,
Colin. / comments
Hi webrunner,
You can choose to apply either the v3.10 patch, or to upgrade to v4.2, irrespective of your support status. There are some minor performance / data collection implications if you upg...
FYI, SQL Backup Pro v7.7 provides some improved support for AlwaysOn Availability Groups, as documented at http://documentation.red-gate.com/display/SBU7/AlwaysOn+Availability+Groups. Thanks - Colin. / comments
FYI, SQL Backup Pro v7.7 provides some improved support for AlwaysOn Availability Groups, as documented at http://documentation.red-gate.com/display/SBU7/AlwaysOn+Availability+Groups. Thanks - Colin.
Hi Larisa,
Thanks for the follow-up post. FYI, we have a UserVoice feedback site, at https://sqlmonitor.uservoice.com/, which would be a great place to post your suggestions and see what reaction you get.
BTW, are you aware of the configuration options for Long Running Queries, which allow you to exclude queries by SQL process name, and/or exclude queries that contain SQL commands or objects, based on regex matching: does this help with any of your needs?
Best regards,
Colin. / comments
Hi Larisa,
Thanks for the follow-up post. FYI, we have a UserVoice feedback site, at https://sqlmonitor.uservoice.com/, which would be a great place to post your suggestions and see what reaction ...
Hi,
There's a Microsoft feedback portal, for Azure SQL Database feature requests - this would be the place to make such a request, so please feel free to hassle them! :-) http://feedback.azure.com/forums/217321-sql-database
Thanks,
Colin. / comments
Hi,
There's a Microsoft feedback portal, for Azure SQL Database feature requests - this would be the place to make such a request, so please feel free to hassle them! :-)http://feedback.azure.com/...
The issues we fixed were around combinations of keywords, where SQL Server 2014 worked slightly differently to previous releases:
BACKUP USER DATABASES WITH DIFFERENTIAL, FULLIFREQUIRED - the full backup was not being generating if it was required
BACKUP LOGS WITH FULLIFREQUIRED - was generating a wrong exit code
BACKUP WITH CHECKSUM, CONTINUEONERROR - this was returning the wrong error code, if there was an error
BACKUP ALL DATABASES - wasn't properly excluded snapshot databases
Hope this helps,
Colin. / comments
The issues we fixed were around combinations of keywords, where SQL Server 2014 worked slightly differently to previous releases:
BACKUP USER DATABASES WITH DIFFERENTIAL, FULLIFREQUIRED - the full...
Just to add to this:
There are some blog posts to introduce people to the schema. Whilst these are a bit old (early 2013), most of the changes since they were written have been additive to the schema, rather than changing the schema. They might help as a starting point. https://www.simple-talk.com/blogs/author/198217-chris-lambrou/
Also, for situations where you want a very long duration time series, but don't want to keep all the core monitoring data, some customers are using Custom Metrics. This has a couple of benefits of this approach:
- You can configure separate purge settings for the Custom Metrics data;
- You can configure the collection frequency from once per minute to once per day; so again this can limit the volume of data, and can be especially useful for less volatile, slowly changing data.
Hope this helps,
Colin. / comments
Just to add to this:
There are some blog posts to introduce people to the schema. Whilst these are a bit old (early 2013), most of the changes since they were written have been additive to the sch...
Hi,
We're working on this now, and hope to ship in early Q3.
Best regards,
Colin. / comments
Hi,
We're working on this now, and hope to ship in early Q3.
Best regards,
Colin.
A quick comment on why we've not published the schema: it's nothing as nefarious as wanting to in some way protect SQL Monitor's value, but for the practical reason that it takes a lot of effort to manage a public schema, it introduces requirements like version controlling the schema (via public views) and can hamper future development (by introducing a restriction that we must try to ensure we don't break backwards compatibility).
We did publish a short series of SimpleTalk articles about the SQL Monitor schema (https://www.simple-talk.com/blogs/author/198217-chris-lambrou/). These haven't been updated for a while, but actually the schema has been fairly stable since these were written, so these articles should still be helpful in understanding the schema. I believe they will help you pull out some of the data you mention ('though query duration and SQL process fragments might be trickier).
Hope this helps,
Colin. / comments
A quick comment on why we've not published the schema: it's nothing as nefarious as wanting to in some way protect SQL Monitor's value, but for the practical reason that it takes a lot of effort to...