Comments
Sort by recent activity
Hi, first of all, please be aware that the index recommendations done by Red Gate Monitor apply to that specific query. Always confirm with general index recommendations (like not more than seven indexes on one tables) before implementing. Not all software vendors support adding own (custom) indexes, always verify with your vendor first. The code for you index would look like this: CREATE INDEX IX_NAME_OF_INDEX ON [dbname].[dbo].[tablename] ([m_type], [ms_code]) INCLUDE ([level_], [description##1], [description##2], [description##3], [item_id], [document], [type], [form_name], [edit_authority], [spare_2], [params##1], [params##2], [params##3], [params##4], [params##5], [params##6], [params##7], [params##8], [params##9], [params##10], [params##11], [params##12], [params##13], [params##14], [params##15], [posttray_name], [posttray_priority], [prev_item], [PROGRESS_RECID]) WITH (fillfactor = 90, sort_in_tempdb = on); A few important remarks: - Fields marked with include are always red from table (disk) whenever a record is found via the index - options for the indexes in the "WITH" section are generally recommended: - fillfactor = 90 : prevents filling up all pages in the index, will cause index to be a bit bigger on disk, but less page splits - sort_in_tempdb = on : Option only has effect when running on SQL developer or enterprise edition. The index will be rebuild in the tempdb and will than replace the one in the table. Reducing the lock time on your table and improving performance during rebuild. If you have any additional questions, please reach out. / comments
Hi, first of all, please be aware that the index recommendations done by Red Gate Monitor apply to that specific query.Always confirm with general index recommendations (like not more than seven in...
Are you able to do a continuous ping from the base monitor to server#3? See if that shows any connection drops. Have you looked at the logs from SQL Monitor? https://documentation.red-gate.com/sm/maintaining-and-upgrading-sql-monitor/maintaining-sql-monitor/viewing-component-information-and-log-files Do these give you any insight? If possible, turn on a SQL profiler on server#3 and see if any connections come in from the base monitor. Even if the monitor account has insufficient rights, a connection attempt should still pop up in the profiler. / comments
Are you able to do a continuous ping from the base monitor to server#3? See if that shows any connection drops.Have you looked at the logs from SQL Monitor?https://documentation.red-gate.com/sm/mai...
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. / 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-instal...
Alex B said:
Hi all,
After working with @easby in a ticket, the issue is that an old view from v10 remained in the repository that had the same name as a new table being introduced. Running this before updating (or on the repository database after updating and getting the error above) should allow the schema upgrade to continue:
DROP VIEW [settings].[MonitoredEntities]
Kind regards, Alex
Will a revised setup installer be released to check (and potentially solve) this issue during installation? / comments
Alex B said:
Hi all,
After working with @easby in a ticket, the issue is that an old view from v10 remained in the repository that had the same name as a new table being introduced. Running...
Could you perhaps shed some more insight into your environment? What build version does your SQL server and SQL Monitor have? What kind of HW are you hosting the database on? / comments
Could you perhaps shed some more insight into your environment?What build version does your SQL server and SQL Monitor have?What kind of HW are you hosting the database on?
TeunvdBiggelaar said:
I still receive these kinds of errors when im trying to open alerts and i'm on version 13.0.51.53 in our development environment.
I'm guessing your issue is another one than the one Don was facing. He had issues when people were logging in. When viewing an alert you're already logged in? Or are you opening links from emails? Perhaps provide some more details and perhaps open another topic if the issue you're facing is not exactly the same. / comments
TeunvdBiggelaar said:
I still receive these kinds of errors when im trying to open alerts and i'm on version 13.0.51.53 in our development environment.
I'm guessing your issue is another one...
Hi @DonFerguson, We're on 13.0.48 and I just checked with some of our non-admin users and nobody is having issues to log in. / comments
Hi @DonFerguson, We're on 13.0.48 and I just checked with some of our non-admin users and nobody is having issues to log in.
You have to use 'ALTER INDEX' instead of 'INDEX'. Mine is configured like: [image] [image] / comments
You have to use 'ALTER INDEX' instead of 'INDEX'. Mine is configured like:
Here we are again ... Where is DBServer2 located? If it is not in de the same region you need to use async commit. Otherwise delay will cause application issues. I recommend you read through this article: https://learn.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/availability-group-overview?view=azuresql The biggest difference with on-prem is: - Load balancer that is needed in Azure - All nodes inside your cluster need to be a member of an availability set - I also recommend using striped volumes for your SQL files to foresee better performance: https://learn.microsoft.com/en-us/gaming/azure/game-dev-virtual-machine/striped-disks-iops Feel free to contact me afterwards if you still have questions. I've done it in the past on SQL 2016 and by the looks of it , not too much has changed. / comments
Here we are again ...Where is DBServer2 located? If it is not in de the same region you need to use async commit. Otherwise delay will cause application issues.I recommend you read through this art...
Using SQL Monitor to capture queries and plans to search for joins could be a start ? You could focus on most resource consuming queries first allowing you to quickly solve the most pressing issues? / comments
Using SQL Monitor to capture queries and plans to search for joins could be a start ? You could focus on most resource consuming queries first allowing you to quickly solve the most pressing issues?