June 15, 2012 at 6:23 pm
L' Eomot Inversé (6/13/2012)
...Even when I didn't have full control, I usually had a recruitment veto (since the late 70s, anyway, and I didn't meet any DBAs before then) so my main frustration was with my inability to get them to get existing junior DBAs to learn to be competent - that was before I realised that some people are just plain unable to learn technical stuff (and others, like myself, are just plain unable to learn literary criticism or how to be kind to and patient with obstructive red-tape wallahs, despite those abilities being just as important as the ones I have and some others don't)...
Wow. That's a big sentence. With more acronyms thrown in you'd give the red-tapers a real run for their money! :hehe:
...One of the symptoms of an approaching nervous breakdown is the belief that ones work is terribly important.... Bertrand Russell
June 18, 2012 at 11:16 am
Interesting thread.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 9, 2012 at 8:37 am
Good question!
August 24, 2012 at 7:30 am
It might not be possible to get the DAC port from the error log if the error logs are cycled frequently. In that case you could restart the SQL Server service to obtain the DAC port, but that would probably clear the problem that required you to attempt a DAC connection in the first place! Not to mention peeing off a lot of users if there was actually no problem: they were working merrily away and you just happened to be testing the DAC for your own amusement.
On a clustered instance, the DAC port is dynamically assigned so unless you specified a dynamic port range to be open on your firewall (something that the security folks would be dead against), you'd probably not be able to connect (remotely) via the DAC even if you knew the port number.
The only option left would be to connect via the DAC locally which assumes that you could either get to the server physically or RDP to it.
The scenario I have in mind is where your server is in a hosted DataCenter which is physically and logically (i.e. firewalls, different domain) separated from your place of work........which just so happens to be the scenario I work in. 😉
Regards
Lempster
May 28, 2013 at 5:15 pm
@Ten Centuries - Perfect!!!
Thanks for the sqlcmd bit - that did the trick for me.
My current configuration is both SQL and DAC running on non-standard ports (say 41433 and 41434 respectively), browser service is disabled and Hide Instance is enabled (all of these from CIS Benchmark recommendations)
I was running into a brickwall being able to connecto to the DAC through Management Studio - using sqlcmd from the command line did the trick. Noting that you did not include the -A to have sqlcmd connect over the DAC I tested stripping out "ADMIN:" from the Management Studio connection and that seems to be working perfectly.
I connected to: <servername>,41434 - that worked perfectly.
Next I verified I was using the DAC by attempting to make another connection over 41434 and ran into DAC in use error.
Viewing 5 posts - 31 through 34 (of 34 total)
You must be logged in to reply to this topic. Login to reply