DBA by trade... No really, wanna trade? Unfortunately, I've only achieved 66.66% uptime, my system continually crashes between 12-6 am. Maybe I need a patch!
Hey friends! Want to work somewhere exciting and fun? Great colleagues and perks? Make a difference in helping people find love and connection? Then check this out & apply or let me know if you want more info #sql#BigData#aws#sqlserver#databricks
https://t.co/itXoEAPBqY
@SQLSocialite FYI I solved it myself. The standby.signal file wasn't in the expected location, and I had to use "SHOW data_directory;" to find the correct one and remove the trigger file there.
FYI I solved it myself. The standby.signal file wasn't in the expected location, and I had to use "SHOW data_directory;" to find the correct one and remove the trigger file there.
I actually updated the question as it's the reverse where the standby is trying to connect to the primary, not the other way around. However I've already ensured the primary_conninfo is removed as well as the trigger file, so it's still an issue.
@SQLSocialite Thanks Scott! I actually updated the question as it's the reverse where the standby is trying to connect to the primary, not the other way around. However I've already ensured the primary_conninfo is removed as well as the trigger file, so it's still an issue.
@PaulRandal@ReidDeWolfe Here's the Client Statistics from the other test server, which shows query profile and network statistics to be the same, but with vastly different Client processing times.
Why does a 3000 line row-by-row INSERT script perform better with a GO after each statement than without? Script is only 481KB and takes a few seconds with GO and a few minutes without. It canβt all be parse/compile? #sqlhelp
@PaulRandal@ReidDeWolfe As well, I'm only testing this script against SSMS. It's actually generated and run by Redgate DLM tool, so I imagine it's using SQLCMD already and encountering the same issue.
@PaulRandal@ReidDeWolfe This script is an example of what gets created using Redgate's DLM tool to deploy changes. For now, we're using the option to split transactions/batch operations to reduce the time it takes. Couldn't find much documentation on what Client Processing Time issues could be.
@PaulRandal@ReidDeWolfe It should be noted I've already checked for log/data growth, and we've taken a look for errors in the SAN storage and networking layer, but haven't come up with anything. Memory and CPU are under-utilized, and MAXDOP settings are set to 0. No errors or of IO latency in logs.
@stridergdm I compared Client Stats with and without GO, and though packets and bytes sent/received were more with GO, Client Processing Time was nothing in comparison, though Wait Time on Server Replies increased slightly.