QOD 11/25
-
Although this question is highly technical, I was able to get the answer in only a few minutes of research using online help. I suspect that most of the people that got this question correct took the time to do a little research. Am I correct?
-
Yes, but there nothing wrong with knowing how to search for information
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
It's true that this question can be answered with a small amount of research - I did the same thing. However, the point of the question isn't always knowing the answer, it's how you find it, what you learn when you're looking for it and whether you agree with it when you do find it. I think QOD for 21/11 proves that
! As a developer I don't often have to worry too much about the administration of SQL Server but it's still interesting to read about topics I wouldn't normally come into contact with, such as how SQL server's underlying storage structure works. (hmmmm, how sad is it that I find that stuff interesting?!) It's up to you whether you read just enough to find out the answer or take the opportunity to read a bit more whilst you're looking.
Cheers,
mia
Life moves pretty fast. If you don't stop and look around once in a while, you could miss it. -
Surely it's the same for every question.
The answer isn't a secret, the information required to answer the question is out there somewhere. Some of it you will already know, some you will need to research.
SQL Server (and IT in general) is such a complex and fast changing world that it's impossible to know everything. Even if you do, it's all changed the next day, and you have to learn it all over again.
This is why sites such as this one are becoming more popular.
-
I always answer without researching. Except for today. And if 60-something percent of respondents got this one right, it means they went and looked it up. (I look it up after if I get the answer wrong.)
-
In 95% of cases I research it first, whether that's looking in BOL, testing, or using sqlservercentral's new-fangled google search.
My brain's storage is reserved for important stuff, like my wife's birthday, our anniversary date, and who owes me money. Who cares how many bytes in an extent? All I need to remeber is where to look.
Mind you, I do often get caught out in meetings... my standard answer to anything technical is "I'll get back to you on that".
Cheers,
- Mark
Cheers,
- Mark -
Gee. What's the point of answering after you look it up? Everyone should get 100% that way. If there is a question I can't answer after research, I think I would feel badly.
I think it is much better to answer before the research. That way, you get a good feel for how much you know versus the community.
Larry Ansley
Atlanta, GA
Larry Ansley
Atlanta, GA -
mccork - you remember your wife's birthday & anniversary? Wow, that's impressive. I use outlook's calendar to remember.
Hey, if anyone's interested, I have a challenging question - what to do when you need to perform an action based on a select query? Check it out here: http://www.sqlservercentral.com/forum/topic.asp?TOPIC_ID=18535&FORUM_ID=9&CAT_ID=1&Topic_Title=Trigger+from+Select+Query%3F&Forum_Title=General
I want to see if someone can find a better solution than mine.
Data: Easy to spill, hard to clean up!
-
quote:
My brain's storage is reserved for important stuff, like my wife's birthday, our anniversary date, and who owes me money.As long as it is not the other way round, it's ok
To me, that is what QOD is all about.
Got a question, think about it, research it, post your answer, get points ot not (that's of less importance).
..But (hopefully) next time you'll face such a situation in your real life, you'll remember where to look for the answer.
Once again, to me it's not about being able to answer the question straight out of my head - too much unnecessary and unimportant things to remember you won't get paid for in no way - but to know where to look and how to look.
As for Larry:
If you answer before doing research, are you doing it after answering (wrong or right)?
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
I got it wrong because I assumed that an extent was still 2K as it was in SQL 6.5. Yee Gods I hate it when a unit of measure is variable. What would happen if the value of PI fluctuated.
I tend to answer these questions without looking them up because I want to test my knowledge.
When I get asked a question in the "real world" I tend to double-check it. It is too risky for a DBA to wing it!
He was not wholly unware of the potential lack of insignificance.
-
quote:
As for Larry:If you answer before doing research, are you doing it after answering (wrong or right)?
Always if wrong. Usually not if right. But David's comment about this is right on the money. In the "real world", if you don't know it like the back of your hand, it's good to double check. This is why BOL is my best friend. Sad...
Larry Ansley
Atlanta, GA
Larry Ansley
Atlanta, GA -
I don't mean to sound arrogant about this, but the only shock I had with this question was that it was worth 3 points. This is a simple question - the extent size for SQL Server has been 64K (8 contiguous 8K pages) since the release of SQL 7 back in the last millenium. If you don't know the extent size, then you don't know the basic i/o size for scans, and you are going to have a hard time doing basic i/o tuning.
So I'd say that the reason 60-some percent of the people got this right is just that it's an easy question, whether or not you have to research it.
And btw, not to sound even more like a grump, but somebody mentioned something about 2K extents in SQL 6.5. If memory serves me correctly, although it's been a long time now, an extent in SQL 6.5 was still defined as 8 contiguous pages, which would have been 16K.
Hope I don't get flamed for this, but I think some people are making the mistake of assuming that just because a question is difficult (or arcane) for them means that it's tough for most others also. This is just an easy thing that either you know or you don't know.
-
I wouldn't have put it at 3 points and yes and extent was/is 8 contigious pages in SQL.
When I moved from SQL6.5 through 7 to 2000 I must admit that the last thing on my mind was to say "hey wow, I must look up the extent size!".
I'll come clean and say that in 10 years with SQL Server I've never actually done ANY IO tuning so extent size to me is irrelevant.
He was not wholly unware of the potential lack of insignificance.
-
quote:
I've never actually done ANY IO tuning so extent size to me is irrelevant.I'm curious myself. How does knowing the extent size affect tuning decisions? I've done a fair amount of tuning, and I can't think of how possessing this arcane bit of knowledge helped me.
Larry Ansley
Atlanta, GA
Larry Ansley
Atlanta, GA -
quote:
quote:
I've never actually done ANY IO tuning so extent size to me is irrelevant.I'm curious myself. How does knowing the extent size affect tuning decisions? I've done a fair amount of tuning, and I can't think of how possessing this arcane bit of knowledge helped me.
Larry Ansley
Atlanta, GA
When you set up your disk i/o systems, you need to configure them based on what typical physical i/o patterns will be. Physical SQL Server i/o patterns are determined by a) the page size, b) the extent size and c) how SQL Server reads and writes pages and extents. I should've been clear that I was talking about *physical* i/o tuning - the tuning of the marriage of SQL Server to its disks. This is not as important of an issue with *logical* query tuning - the selection of indexes, etc.
In the past, lots of the disk vendors (Compaq - now HP - comes to mind) have published guides for tuning their hardware for optimal SQL Server physical performance. The Compaq papers in particular did a good job of explaining SQL Server's physical i/o patterns and how to tune your systems to exploit those patterns. You may want to search the HP/Compaq Web site for such papers. Their paper on SQL 7 had lots of this kind of information. HP's site now requires a (free) registration, by the way.
Most people are familiar with the logic of putting logs onto striped devices (without parity) since logs are write-intensive, they can be a bottleneck point for overall system performance, and log writes are the one physical i/o a user *must* wait for (at commit time). Putting logs on a parity device slows log i/o because it requires parity calculation. You can run a SQL Server for a long time and not be aware of these issues, however, and if your systems people are good, they may set the system up correctly for you anyway. This extent-size issue is similar, in that you can know a lot about SQL and not know about this - I'll grant that. Maybe I was in a grouchy mood when I posted the first time. But knowing that SQL likes to read in 64K chunks (I'm simplifying here) is good information when you're picking a stripe size for your disk devices, isn't it?
Chris
Edited by - chrisleonard on 12/02/2003 07:49:22 AM
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply