June 8, 2016 at 11:39 am
Ed Wagner (6/8/2016)
Lynn Pettis (6/8/2016)
Ed Wagner (6/8/2016)
SQLRNNR (6/8/2016)
Ed Wagner (6/8/2016)
Jeff Moden (6/7/2016)
Lynn Pettis (6/7/2016)
Hugo Kornelis (6/7/2016)
GilaMonster (6/7/2016)
What I've advised for years is to notify on lack of success (eg: have a monitoring server check that the backup ran, and if it didn't, send mail)And then have another server monitor the monitoring server, and mail you when it has problems.
And then another, and another , ... when does the monitoring end? :w00t:
When the users call with a problem that you forgot to monitor for. 😉
There will always be one. The best one would be when one of the monitors sends an email saying that the email server is down. 😛
No joke. A client had an email alert just for that. Email if the email server is down. Then they wondered why they didn't get any email when the email server was down.
I've also heard of that exact same logic being proposed before. I must have had to most confused look on my face, almost like there was some part of it I missed. When I pointed out the error in their logic, it took them a minute to process it before they saw the light. It was so funny to see their expressions change when they realized the truth.
Naturally, this led me to a number of funny followups later. Because they believe that email is the "true documentation" for everything, does that mean the problem didn't exist because it wasn't in an email? Even better, because there was no email that the email server was down, did it really go down? 😛
So where is the backup email server that should take over when the primary email server goes down so the email still goes through?
Yeah, you would think that there would be one, but there's no budget for one. :w00t:
Na, they just did not get the email.
I'll get my coat.
June 8, 2016 at 11:41 am
Lynn Pettis (6/7/2016)
Hugo Kornelis (6/7/2016)
GilaMonster (6/7/2016)
What I've advised for years is to notify on lack of success (eg: have a monitoring server check that the backup ran, and if it didn't, send mail)And then have another server monitor the monitoring server, and mail you when it has problems.
And then another, and another , ... when does the monitoring end? :w00t:
Monitoring server monitors all. One server looks at the monitoring server, which is already watched by the Monitor server.
So,
Server A has a monitoring process that looks at
- Server B
- Server C
- Server D
Server D has a process that watches Server A
If D goes down, you get an alert (from Server A) and know your monitoring server is not being watched.
If A goes down, D lets you know.
This doesn't have to be too complicated. In the nuclear industry, we would be triple redundant, so we'd have another server watching both A and D (and being watched). Preferably off site.
However if you lose a data center, you could lose all. You can manage this with one remote monitor. It could be watched, but what I've done is have it send a positive note to a server which records a time. If xxx time passes without a positive note, send a different alert.
This isn't that complex. You have dual watchers, not dependent on each other.
June 8, 2016 at 11:56 am
Steve Jones - SSC Editor (6/8/2016)
Lynn Pettis (6/7/2016)
Hugo Kornelis (6/7/2016)
GilaMonster (6/7/2016)
What I've advised for years is to notify on lack of success (eg: have a monitoring server check that the backup ran, and if it didn't, send mail)And then have another server monitor the monitoring server, and mail you when it has problems.
And then another, and another , ... when does the monitoring end? :w00t:
Monitoring server monitors all. One server looks at the monitoring server, which is already watched by the Monitor server.
So,
Server A has a monitoring process that looks at
- Server B
- Server C
- Server D
Server D has a process that watches Server A
If D goes down, you get an alert (from Server A) and know your monitoring server is not being watched.
If A goes down, D lets you know.
This doesn't have to be too complicated. In the nuclear industry, we would be triple redundant, so we'd have another server watching both A and D (and being watched). Preferably off site.
However if you lose a data center, you could lose all. You can manage this with one remote monitor. It could be watched, but what I've done is have it send a positive note to a server which records a time. If xxx time passes without a positive note, send a different alert.
This isn't that complex. You have dual watchers, not dependent on each other.
Okay, sorry for sarcastic/ironic humor I was trying to use. :ermm:
June 8, 2016 at 12:04 pm
<headdesk>
User asks me to move this bit of code into QA:
ALTER TABLE MyTable
ADD Col1 INT,
Col2 INT
GO
I push back and say "Please add your statement terminator" because all these users have a copy of the DB Standards which require them to use statement terminators and do other things.
User updates the code in TFS as such:
ALTER TABLE MyTable
ADD Col1 INT,
Col2 INT
GO;
Thing is, the user usually knows exactly where the terminators go and usually never misses them. I can only assume the user is having one of those days.
But still, it was good for a bit of a laugh.
June 8, 2016 at 12:07 pm
Brandie Tarvin (6/8/2016)
<headdesk>User asks me to move this bit of code into QA:
ALTER TABLE MyTable
ADD Col1 INT,
Col2 INT
GO
I push back and say "Please add your statement terminator" because all these users have a copy of the DB Standards which require them to use statement terminators and do other things.
User updates the code in TFS as such:
ALTER TABLE MyTable
ADD Col1 INT,
Col2 INT
GO;
Thing is, the user usually knows exactly where the terminators go and usually never misses them. I can only assume the user is having one of those days.
But still, it was good for a bit of a laugh.
And after picking yourself up off the floor and dusting yourself off, you still had to send it back again. 😀
June 8, 2016 at 12:31 pm
Lynn Pettis (6/8/2016)
Brandie Tarvin (6/8/2016)
<headdesk>User asks me to move this bit of code into QA:
ALTER TABLE MyTable
ADD Col1 INT,
Col2 INT
GO
I push back and say "Please add your statement terminator" because all these users have a copy of the DB Standards which require them to use statement terminators and do other things.
User updates the code in TFS as such:
ALTER TABLE MyTable
ADD Col1 INT,
Col2 INT
GO;
Thing is, the user usually knows exactly where the terminators go and usually never misses them. I can only assume the user is having one of those days.
But still, it was good for a bit of a laugh.
And after picking yourself up off the floor and dusting yourself off, you still had to send it back again. 😀
And why not ask them to make it idempotent while you're at it:
IF COL_LENGTH('dbo.mytable', 'col1') IS NULL
BEGIN
ALTER TABLE dbo.mytable
ADD Col1 INT;
END;
June 8, 2016 at 12:38 pm
Lynn Pettis (6/8/2016)
Steve Jones - SSC Editor (6/8/2016)
Lynn Pettis (6/7/2016)
Hugo Kornelis (6/7/2016)
GilaMonster (6/7/2016)
What I've advised for years is to notify on lack of success (eg: have a monitoring server check that the backup ran, and if it didn't, send mail)And then have another server monitor the monitoring server, and mail you when it has problems.
And then another, and another , ... when does the monitoring end? :w00t:
Monitoring server monitors all. One server looks at the monitoring server, which is already watched by the Monitor server.
So,
Server A has a monitoring process that looks at
- Server B
- Server C
- Server D
Server D has a process that watches Server A
If D goes down, you get an alert (from Server A) and know your monitoring server is not being watched.
If A goes down, D lets you know.
This doesn't have to be too complicated. In the nuclear industry, we would be triple redundant, so we'd have another server watching both A and D (and being watched). Preferably off site.
However if you lose a data center, you could lose all. You can manage this with one remote monitor. It could be watched, but what I've done is have it send a positive note to a server which records a time. If xxx time passes without a positive note, send a different alert.
This isn't that complex. You have dual watchers, not dependent on each other.
Okay, sorry for sarcastic/ironic humor I was trying to use. :ermm:
We had an AS400 running a daily batch which varied in finish time, after which it triggered our SQL load and cube build.
Was a bit different, as the schedule could vary by an hour or two during the week, and Saturday batch on the AS400 ran earlier.
SCOM looked for a success message for our process starting by midnight.
AS400 monitored for our process finishing within a few hours.
So we had a similar type of redundancy in place, including a heads up if something was running late.
Wasn't too hard to get setup, and actually very little fell through the cracks.
June 8, 2016 at 1:26 pm
Brandie Tarvin (6/8/2016)
<headdesk>User asks me to move this bit of code into QA:
ALTER TABLE MyTable
ADD Col1 INT,
Col2 INT
GO
I push back and say "Please add your statement terminator" because all these users have a copy of the DB Standards which require them to use statement terminators and do other things.
User updates the code in TFS as such:
ALTER TABLE MyTable
ADD Col1 INT,
Col2 INT
GO;
Thing is, the user usually knows exactly where the terminators go and usually never misses them. I can only assume the user is having one of those days.
But still, it was good for a bit of a laugh.
I had to (politely) beat on an end-user for running this against their database the other day:
SELECT A.COL1
, B.COL2
FROM TBLA A, TBLA B
There are only around 5 million rows or so in the table they were hitting...
What's a mere 25 trillion records being pushed back to their SSMS between friends?
Plus blocking several updates from their application...
:hehe:
June 8, 2016 at 2:11 pm
Mention Dynamic SQL and suddenly that is THE solution for the immediate problem, but what problems may it cause down the road?
Won't be surprised if we hear from that OP again later.
June 8, 2016 at 2:26 pm
Lynn Pettis (6/8/2016)
Okay, sorry for sarcastic/ironic humor I was trying to use. :ermm:
I wasn't sure there was sarcasm or humor involved. I've certainly been a part of conversations where people use this logic to avoid depending or configuring monitoring.
If it was a joke, that's fine, but I just wanted to make sure the "who watches the watchers to infinity" wasn't taken seriously.
June 8, 2016 at 2:37 pm
jasona.work (6/8/2016)
I had to (politely) beat on an end-user for running this against their database the other day:
SELECT A.COL1, B.COL2
FROM TBLA A, TBLA B
There are only around 5 million rows or so in the table they were hitting...
What's a mere 25 trillion records being pushed back to their SSMS between friends?
Plus blocking several updates from their application...
:hehe:
What's a mere 25 trillion rows? A bunch of reads. The old syntax of joining tables leads to a missed join in the where clause and the resulting cartesian plane. I much prefer the explicit INNER/OUTER/CROSS syntax for this and other reasons.
June 8, 2016 at 2:39 pm
Lynn Pettis (6/8/2016)
Mention Dynamic SQL and suddenly that is THE solution for the immediate problem, but what problems may it cause down the road?Won't be surprised if we hear from that OP again later.
No kidding!!! Not sure they understand why it works for them in the otherwise awful sounding situation.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
June 8, 2016 at 2:40 pm
Lynn Pettis (6/8/2016)
Mention Dynamic SQL and suddenly that is THE solution for the immediate problem, but what problems may it cause down the road?Won't be surprised if we hear from that OP again later.
Not only is it THE solution to the immediate problem, but probably all future problems. Everyone's looking for the silver bullet that solves everything. They don't look at it as one tool in a toolbox. One tool to rule them all...
June 9, 2016 at 6:02 am
Ed Wagner (6/8/2016)
jasona.work (6/8/2016)
I had to (politely) beat on an end-user for running this against their database the other day:
SELECT A.COL1, B.COL2
FROM TBLA A, TBLA B
There are only around 5 million rows or so in the table they were hitting...
What's a mere 25 trillion records being pushed back to their SSMS between friends?
Plus blocking several updates from their application...
:hehe:
What's a mere 25 trillion rows? A bunch of reads. The old syntax of joining tables leads to a missed join in the where clause and the resulting cartesian plane. I much prefer the explicit INNER/OUTER/CROSS syntax for this and other reasons.
My favourite version of this are reporting systems which generate this type of code
SELECT DISTINCT
A.COL1
, B.COL2
FROM TBLA A, TBLA B
which renders even the beefiest servers useless
😎
June 9, 2016 at 6:16 am
Ed Wagner (6/8/2016)
Lynn Pettis (6/8/2016)
Mention Dynamic SQL and suddenly that is THE solution for the immediate problem, but what problems may it cause down the road?Won't be surprised if we hear from that OP again later.
Not only is it THE solution to the immediate problem, but probably all future problems. Everyone's looking for the silver bullet that solves everything. They don't look at it as one tool in a toolbox. One tool to rule them all...
Dynamic SQL with NOLOCK!
Fixes all problems, even your clogged kitchen sink. @=)
Viewing 15 posts - 54,511 through 54,525 (of 66,815 total)
You must be logged in to reply to this topic. Login to reply