September 14, 2011 at 1:15 pm
Ninja's_RGR'us (9/14/2011)
Default autogrowth settingsDelete frees space (as in shrink the file)
AUTOSHRINK
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
September 14, 2011 at 1:23 pm
Grant Fritchey (9/14/2011)
Changing the topic for a moment, I'd like to beg some ideas from the group, again.I'm tasked with writing another article. This one is all about the scary, crazy stuff that the uninformed can do because of how SQL Server is setup and documented. As the one HUGE glaring example, the ability to just run DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS. Not just the ability, but the active encouragement. Another one that immediately comes to mind is the use of the NO_LOCK hint as the RUN_FASTER hint. What are a few others?
How about not setting appropriate growth settings on your data and log files. Silly little things like 1 or 10 percent (or MB) growth. I have inherited databases, 100+ GB, that were set to 1% growth in both log and data files. Yeah - it was ugly.
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
September 14, 2011 at 1:23 pm
SQLRNNR (9/14/2011)
Grant Fritchey (9/14/2011)
Changing the topic for a moment, I'd like to beg some ideas from the group, again.I'm tasked with writing another article. This one is all about the scary, crazy stuff that the uninformed can do because of how SQL Server is setup and documented. As the one HUGE glaring example, the ability to just run DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS. Not just the ability, but the active encouragement. Another one that immediately comes to mind is the use of the NO_LOCK hint as the RUN_FASTER hint. What are a few others?
Pick your trace flag, undocumented or documented, that may be found on the internet.
Yup.
I had a recent PM from someone saying that they were an Oracle DBA, new to SQL and wanted me to give them a specific traceflag 'just for testing'
I refused, way too much scope for misusing something, I pointed them at docs instead.
The traceflag they wanted - 4136
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 14, 2011 at 2:24 pm
SQLRNNR (9/14/2011)
Grant Fritchey (9/14/2011)
Changing the topic for a moment, I'd like to beg some ideas from the group, again.I'm tasked with writing another article. This one is all about the scary, crazy stuff that the uninformed can do because of how SQL Server is setup and documented. As the one HUGE glaring example, the ability to just run DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS. Not just the ability, but the active encouragement. Another one that immediately comes to mind is the use of the NO_LOCK hint as the RUN_FASTER hint. What are a few others?
How about not setting appropriate growth settings on your data and log files. Silly little things like 1 or 10 percent (or MB) growth. I have inherited databases, 100+ GB, that were set to 1% growth in both log and data files. Yeah - it was ugly.
I'm glad you agree with just about anything I've suggested ;-).
September 14, 2011 at 2:42 pm
Ninja's_RGR'us (9/14/2011)
SQLRNNR (9/14/2011)
Grant Fritchey (9/14/2011)
Changing the topic for a moment, I'd like to beg some ideas from the group, again.I'm tasked with writing another article. This one is all about the scary, crazy stuff that the uninformed can do because of how SQL Server is setup and documented. As the one HUGE glaring example, the ability to just run DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS. Not just the ability, but the active encouragement. Another one that immediately comes to mind is the use of the NO_LOCK hint as the RUN_FASTER hint. What are a few others?
How about not setting appropriate growth settings on your data and log files. Silly little things like 1 or 10 percent (or MB) growth. I have inherited databases, 100+ GB, that were set to 1% growth in both log and data files. Yeah - it was ugly.
I'm glad you agree with just about anything I've suggested ;-).
I missed that one. If only I had seen it I would have opposed it 😀
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
September 14, 2011 at 2:47 pm
One step closer to becoming a reality.
Read here to find out more.
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
September 14, 2011 at 2:55 pm
Grant Fritchey (9/14/2011)
Changing the topic for a moment, I'd like to beg some ideas from the group, again.I'm tasked with writing another article. This one is all about the scary, crazy stuff that the uninformed can do because of how SQL Server is setup and documented. As the one HUGE glaring example, the ability to just run DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS. Not just the ability, but the active encouragement. Another one that immediately comes to mind is the use of the NO_LOCK hint as the RUN_FASTER hint. What are a few others?
First thing that comes in mind:
- make a sqluser sysadmin in an effort to overcome/bypass a single problem and causing applications that run using that sqluser to get "invalid object" because schema hasn't been coded.
- compress a backup folder or drive, causing backup statements taking several factors ( yes factors ) more time.
(couple of minutes going to +24hours)
- backup database log ( tsql or via ssms ) in a hurry to clear it because of a looped app and without copying it to the safe zone, as coded in regular backup jobs, causing a breach in recovery chain.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
September 14, 2011 at 2:58 pm
jcrawf02 (9/14/2011)
Grant Fritchey (9/14/2011)
mtillman-921105 (9/14/2011)
Grant Fritchey (9/14/2011)
Changing the topic for a moment, I'd like to beg some ideas from the group, again.I'm tasked with writing another article. This one is all about the scary, crazy stuff that the uninformed can do because of how SQL Server is setup and documented. As the one HUGE glaring example, the ability to just run DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS. Not just the ability, but the active encouragement. Another one that immediately comes to mind is the use of the NO_LOCK hint as the RUN_FASTER hint. What are a few others?
Using the FLOAT data type comes to mind.
BTW, way to go JEFF! :w00t:
You combined Jeff & FLOAT. You're going to get the lecture now about the evils of the DECIMAL data type. I'm sorry, but you've brought this on yourself.
alright, little help, what the hell is wrong with FLOAT?
I think a Floating Jeff exception only occurs when a hacker causes a sqlbeer flood :w00t:
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
September 14, 2011 at 3:26 pm
I'm chiming in late because I've been on the road all day - CONGRATULATIONS JEFF!!!!
-Ki
September 14, 2011 at 3:37 pm
Stefan Krzywicki (9/14/2011)
GSquared (9/14/2011)
....
Edit: Deleted the rest of my post because this debate is just looney at this point. Shouldn't have brought it back up.
I found another interesting statistic. If you have any money at all, in your pocket/wallet/purse, in a bank account or available as credit, that puts you in the wealthiest 8% of the planet's population. Still looking for the source study on that one, so accuracy and up-to-dateness aren't satisfied yet, but if it's true (and it does align with other stats I can source), it puts a lot into perspective. Take this as just interesting trivia, not an assertion of anything about anything at all.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
September 14, 2011 at 4:04 pm
Not continuing the debate, just to show another perspective:
http://www.hsrc.ac.za/HSRC_Review_Article-47.phtml (from 2006)
The surveys asked citizens whether they agree that ‘my household is able to get enough food for its needs’. A comparison of the SASAS surveys reveals that the white respondents consistently succeeded much better than Indian, coloured and black respondents in securing enough food for their household needs (Figure 1). The 2005 survey found that 91.3% of the white respondents agree with the statement, whereas 85.9% of Indians, 65.2% of coloureds and 48.5% of blacks agreed.
http://www.sarpn.org/documents/d0000990/ (from 2004)
Approximately 57% of individuals in South Africa were living below the poverty income line in 2001, unchanged from 1996. Limpopo and the Eastern Cape had the highest proportion of poor with 77% and 72% of their populations living below the poverty income line, respectively. The Western Cape had the lowest proportion in poverty (32%), followed by Gauteng (42%).
and
Poverty estimates are calculated using a poverty line that varies according to household size. A household of 4 persons has a poverty income of R1 290 per month. All monetary values are measured in constant 2001 prices.
(that works out around $50 per person per month)
A government publication from 2007 estimated that the figure had increased to 63%
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 14, 2011 at 4:13 pm
ALZDBA (9/14/2011)
jcrawf02 (9/14/2011)
Grant Fritchey (9/14/2011)
mtillman-921105 (9/14/2011)
Grant Fritchey (9/14/2011)
Changing the topic for a moment, I'd like to beg some ideas from the group, again.I'm tasked with writing another article. This one is all about the scary, crazy stuff that the uninformed can do because of how SQL Server is setup and documented. As the one HUGE glaring example, the ability to just run DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS. Not just the ability, but the active encouragement. Another one that immediately comes to mind is the use of the NO_LOCK hint as the RUN_FASTER hint. What are a few others?
Using the FLOAT data type comes to mind.
BTW, way to go JEFF! :w00t:
You combined Jeff & FLOAT. You're going to get the lecture now about the evils of the DECIMAL data type. I'm sorry, but you've brought this on yourself.
alright, little help, what the hell is wrong with FLOAT?
I think a Floating Jeff exception only occurs when a hacker causes a sqlbeer flood :w00t:
Hmmm... maybe I can teach the dust bunnies something new. Anyone up for a "beer float"? YUM! 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2011 at 4:20 pm
Jack Corbett (9/14/2011)
Grant,Defaulting all character columns to varchar or, even worse, nvarchar and then compounding it by using 255.
No statistics or index maintenance.
Then echoing just about everything else everyone else said.
On that note, the developers at work use some sort of Visual Studio "wizard" to make tables... all character based columns are automatically set to NVARCHAR(4000). When I asked why they allow the defaults to prevail, I was told they don't believe in "premature optimization". Maybe that's why the dust bunnies recently built me a rare 3-band Pork Chop launcher.
I'd also like to see someone talk about one of the worst things ever... the belief that "Set Based" somehow means "All in One Query".
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2011 at 4:25 pm
Jeff Moden (9/14/2011)
On that note, the developers at work use some sort of Visual Studio "wizard" to make tables... all character based columns are automatically set to NVARCHAR(4000). When I asked why they allow the defaults to prevail, I was told they don't believe in "premature optimization".
Whoa Nelly.
Not a fan of the MS defaults via the tools.
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
September 14, 2011 at 4:34 pm
Grant Fritchey (9/14/2011)
mtillman-921105 (9/14/2011)
Grant Fritchey (9/14/2011)
You combined Jeff & FLOAT. You're going to get the lecture now about the evils of the DECIMAL data type. I'm sorry, but you've brought this on yourself.Oh, DECIMAL's all I ever use in its stead just about... Then, well maybe I need the lecture. I'm primarily a student here anyway. :laugh:
It takes an Exceptional DBA to explain that one, so we'll need to wait for Jeff.
Gosh... the question of whether to use FLOAT or DECIMAL has come up often enough, I'm going to have to go back though some of my old posts and some of my old electronics books on the differences between binary and decimal adders and maybe write an article on the subject. I do, however, think that there are folks in our midst that are much more qualified than I to write such an article. They've probably forgotten more about math than I've ever learned. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 29,866 through 29,880 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply