April 23, 2018 at 1:52 am
Lynn Pettis - Wednesday, April 18, 2018 2:19 PMLynn Pettis - Tuesday, April 17, 2018 10:26 PMWell, today has been a day. I received a call from my dad while I was at work, and all he said was he was stuck on the floor. All I could think of was that he had sat on the floor to do to something and then couldn't get back up. Needless to say I hurried home to find him laying face down in the hallway. His walker was still upright. First question I asked him was if he fell. He answered no, that his legs started getting weak so he climbed down the walker until he was on the floor. Well, I called 911 and shortly after I had an ambulance and the fire department at the house.Well, I will spare the details, HIPPA and all, but he is currently in the hospital and we will see what happens from here.
I really don't need days like this, it is very stressful.
Well, an update. Got a call this morning from the cardiologist and they were going to put in a pacemaker this morning. Well, everything went well, but don't trust the times that a doctor tells you. The procedure was supposed to start at 9 AM, didn't start until almost 10 AM. The procedure did meet the time (about an hour) the doctor told me. But then he told me that dad would be back in his room in 45 minutes but that was actually over two hours.
I am exhausted.
My GF's dad was fitted with a pacemaker around six years ago, it's made a significant improvement to his quality of life. I hope your dad's better soon.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
April 23, 2018 at 2:34 am
Jeff Moden - Friday, April 20, 2018 9:07 AMShifting gears a bit, I'm giving a new presentation here in the Detroit area for the local PASS Chapter on the 10th of May. I was limited to 1000 bytes for description (for possible SQL Saturday offerings) and so it's a bit understated but here's the description from EventBrite and the EventBrite link to register (it's free, of course) if you'd like to attend. I'm also very much looking forward to Chris Morris coming into town for the day. The man is definitely on my bucket list.
https://www.eventbrite.com/e/black-arts-index-maintenance-tickets-45321644258Black Arts Index Maintenance
The most common reasons to do Index Maintenance are to defragment indexes to ensure that they continue to provide good performance and to control how much space they occupy both on disk and in memory.
Ironically, thousands, perhaps even millions of people are unwittingly destroying the full potential of their indexes and are actually injecting guaranteed performance and space usage problems into their indexes by using current, widely-accepted “Best Practice†Index Maintenance methods. To top off the atrocities, all of this results in hundreds of thousands of totally unnecessary log file entries, slowing performance even more.
In this SQL “Black Arts†session, Jeff Moden graphically demonstrates why and how current “Best Practice†Index Maintenance methods are causing all of those performance problems and two very simple methods to “auto-magically†fix those problems (including automatic adaptive Fill Factor determination) and virtually eliminate all bad page splits in the process.
Thanks Jeff, I'm so looking forward to this presentation. It's absolutely on point with the work I've been doing for the last couple of years. And, given how much influence your work has had on my career since I stumbled upon your articles 15 years ago, it's going to be quite something to meet you in person.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
April 23, 2018 at 4:12 am
Steve Jones - SSC Editor - Friday, April 20, 2018 12:18 PMOr maybe write an article (or three) on this 😉
Yeah, an article would be good for those of us that are in a different country and are interested in this. 🙂
April 23, 2018 at 7:23 am
jonathan.crawford - Friday, April 20, 2018 7:01 PMJeff Moden - Friday, April 20, 2018 1:05 PMThat and more. I'm a couple of years behind on a lot of partial articles. for example, I really want to finish the "Devils in the Data" mini-series.
so, "Devils in the Data", "Black Arts".....is there something you're not telling us, Jeff? Should we bring an unblemished goat to the presentation for you?
Heh... unblemished code would be more appropriate. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2018 at 7:38 am
Rick-153145 - Monday, April 23, 2018 4:12 AMSteve Jones - SSC Editor - Friday, April 20, 2018 12:18 PMOr maybe write an article (or three) on this 😉
Yeah, an article would be good for those of us that are in a different country and are interested in this. 🙂
A bit of a spoiler but it's that important... Until the article comes out and without all the documentation leading up to it, check your indexes and index maintenance, If you're defragging indexes that have a 0 or 100% Fill Factor, you're killing your system with blocking, lot's of CPU and disk I/O, and causing your log files to contain several times more than they need to. Either assign a correct FILL FACTOR or stop defragging them and let the "Natural Fill Factor" that every index can develop take effect.
The whole thing that kicked this year's long experiment and research off for me was massive blocking the day after index maintenance. Thank the stars for Brent Ozar back in Jan 2016 and, especially lately, Paul Randal for the deep dive presentation he does on the internals of fragmentation. Brent's seeming crazy suggestion saved my sanity and now I know all the reasons why.
Another major finding is that everyone is waiting way too long to defrag. Instead of waiting for 10% fragmentation to Reorg or 30% fragmentation to Rebuild, you should defrag at no more than 1% (and indication that bad page splits are just starting to happen instead of waiting for them to happen enough to cause 10% or more fragmentation) and do it nightly instead of weekly. Not every index will rebuild nightly. Also, if % of page fullness is greater than the Fill Factor, do a Rebuild instead of a Reorg because Reorg will NOT expand pages to make additional space when you need the free space in the index the most.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2018 at 7:49 am
Jeff Moden - Monday, April 23, 2018 7:38 AMA bit of a spoiler but it's that important... Until the article comes out and without all the documentation leading up to it, check your indexes and index maintenance, If you're defragging indexes that have a 0 or 100% Fill Factor, you're killing your system with blocking, lot's of CPU and disk I/O, and causing your log files to contain several times more than they need to. Either assign a correct FILL FACTOR or stop defragging them and let the "Natural Fill Factor" that every index can develop take effect.
The whole thing that kicked this year's long experiment and research off for me was massive blocking the day after index maintenance. Thank the stars for Brent Ozar back in Jan 2016 and, especially lately, Paul Randal for the deep dive presentation he does on the internals of fragmentation. Brent's seeming crazy suggestion saved my sanity and now I know all the reasons why.
Another major finding is that everyone is waiting way too long to defrag. Instead of waiting for 10% fragmentation to Reorg or 30% fragmentation to Rebuild, you should defrag at no more than 1% (and indication that bad page splits are just starting to happen instead of waiting for them to happen enough to cause 10% or more fragmentation) and do it nightly instead of weekly. Not every index will rebuild nightly. Also, if % of page fullness is greater than the Fill Factor, do a Rebuild instead of a Reorg because Reorg will NOT expand pages to make additional space when you need the free space in the index the most.
First two paragraphs are standard where ever I work and if its not at the beginning, it is at the end. 🙂
Last paragraph is more interesting, what about rebuild time etc? I think the reason most do this weekly is simply due to maintenance windows and SLA's (even if you have enterprise, online is only a suggestion, doesn't mean the engine will decide to keep the index online while its rebuilding/reorging).
April 23, 2018 at 7:52 am
ChrisM@Work - Monday, April 23, 2018 2:34 AMJeff Moden - Friday, April 20, 2018 9:07 AMShifting gears a bit, I'm giving a new presentation here in the Detroit area for the local PASS Chapter on the 10th of May. I was limited to 1000 bytes for description (for possible SQL Saturday offerings) and so it's a bit understated but here's the description from EventBrite and the EventBrite link to register (it's free, of course) if you'd like to attend. I'm also very much looking forward to Chris Morris coming into town for the day. The man is definitely on my bucket list.
https://www.eventbrite.com/e/black-arts-index-maintenance-tickets-45321644258Black Arts Index Maintenance
The most common reasons to do Index Maintenance are to defragment indexes to ensure that they continue to provide good performance and to control how much space they occupy both on disk and in memory.
Ironically, thousands, perhaps even millions of people are unwittingly destroying the full potential of their indexes and are actually injecting guaranteed performance and space usage problems into their indexes by using current, widely-accepted “Best Practice†Index Maintenance methods. To top off the atrocities, all of this results in hundreds of thousands of totally unnecessary log file entries, slowing performance even more.
In this SQL “Black Arts†session, Jeff Moden graphically demonstrates why and how current “Best Practice†Index Maintenance methods are causing all of those performance problems and two very simple methods to “auto-magically†fix those problems (including automatic adaptive Fill Factor determination) and virtually eliminate all bad page splits in the process.
Thanks Jeff, I'm so looking forward to this presentation. It's absolutely on point with the work I've been doing for the last couple of years. And, given how much influence your work has had on my career since I stumbled upon your articles 15 years ago, it's going to be quite something to meet you in person.
It'll be an honor for both of us to meet you as well, sir. I just hope the presentation lives up to your expectations.
April 23, 2018 at 7:53 am
Ed Wagner - Monday, April 23, 2018 7:51 AMChrisM@Work - Monday, April 23, 2018 2:34 AMJeff Moden - Friday, April 20, 2018 9:07 AMShifting gears a bit, I'm giving a new presentation here in the Detroit area for the local PASS Chapter on the 10th of May. I was limited to 1000 bytes for description (for possible SQL Saturday offerings) and so it's a bit understated but here's the description from EventBrite and the EventBrite link to register (it's free, of course) if you'd like to attend. I'm also very much looking forward to Chris Morris coming into town for the day. The man is definitely on my bucket list.
https://www.eventbrite.com/e/black-arts-index-maintenance-tickets-45321644258Black Arts Index Maintenance
The most common reasons to do Index Maintenance are to defragment indexes to ensure that they continue to provide good performance and to control how much space they occupy both on disk and in memory.
Ironically, thousands, perhaps even millions of people are unwittingly destroying the full potential of their indexes and are actually injecting guaranteed performance and space usage problems into their indexes by using current, widely-accepted “Best Practice†Index Maintenance methods. To top off the atrocities, all of this results in hundreds of thousands of totally unnecessary log file entries, slowing performance even more.
In this SQL “Black Arts†session, Jeff Moden graphically demonstrates why and how current “Best Practice†Index Maintenance methods are causing all of those performance problems and two very simple methods to “auto-magically†fix those problems (including automatic adaptive Fill Factor determination) and virtually eliminate all bad page splits in the process.
Thanks Jeff, I'm so looking forward to this presentation. It's absolutely on point with the work I've been doing for the last couple of years. And, given how much influence your work has had on my career since I stumbled upon your articles 15 years ago, it's going to be quite something to meet you in person.
It'll be an honor for both of us to meet you as well, sir. I just hope the presentation lives up to your expectations.
Heh.... I'm the one that should be worried about that! 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
April 23, 2018 at 12:17 pm
Rick-153145 - Monday, April 23, 2018 7:49 AMJeff Moden - Monday, April 23, 2018 7:38 AMA bit of a spoiler but it's that important... Until the article comes out and without all the documentation leading up to it, check your indexes and index maintenance, If you're defragging indexes that have a 0 or 100% Fill Factor, you're killing your system with blocking, lot's of CPU and disk I/O, and causing your log files to contain several times more than they need to. Either assign a correct FILL FACTOR or stop defragging them and let the "Natural Fill Factor" that every index can develop take effect.
The whole thing that kicked this year's long experiment and research off for me was massive blocking the day after index maintenance. Thank the stars for Brent Ozar back in Jan 2016 and, especially lately, Paul Randal for the deep dive presentation he does on the internals of fragmentation. Brent's seeming crazy suggestion saved my sanity and now I know all the reasons why.
Another major finding is that everyone is waiting way too long to defrag. Instead of waiting for 10% fragmentation to Reorg or 30% fragmentation to Rebuild, you should defrag at no more than 1% (and indication that bad page splits are just starting to happen instead of waiting for them to happen enough to cause 10% or more fragmentation) and do it nightly instead of weekly. Not every index will rebuild nightly. Also, if % of page fullness is greater than the Fill Factor, do a Rebuild instead of a Reorg because Reorg will NOT expand pages to make additional space when you need the free space in the index the most.
First two paragraphs are standard where ever I work and if its not at the beginning, it is at the end. 🙂
Last paragraph is more interesting, what about rebuild time etc? I think the reason most do this weekly is simply due to maintenance windows and SLA's (even if you have enterprise, online is only a suggestion, doesn't mean the engine will decide to keep the index online while its rebuilding/reorging).
If your FILL FACTOR is correct for any given index, the index can go weeks without needing a defrag. My testing was done with GUIDs, the 2nd worst thing you could build a clustered index on. 😀 The test simulated inserts at the rate of 1000 per hour for 10 hours per day for 365 days. The rows weren't exceptionally wide (123 bytes) but done as I said, a rebuild was only triggered once every 5 or 6 weeks.
Also, not quite correct about the online stuff. Online index rebuilds will, in fact, be online except for a brief bit at the very beginning and the very end of a REBUILD. At least that's what Paul Randal states. If you can prove something to the contrary, then I'm all ears because I'm all for destroying myths and certain practices that have been labeled a "Best Practice" when they're really not.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 24, 2018 at 12:56 am
Jeff Moden - Monday, April 23, 2018 12:17 PMIf your FILL FACTOR is correct for any given index, the index can go weeks without needing a defrag. My testing was done with GUIDs, the 2nd worst thing you could build a clustered index on. 😀 The test simulated inserts at the rate of 1000 per hour for 10 hours per day for 365 days. The rows weren't exceptionally wide (123 bytes) but done as I said, a rebuild was only triggered once every 5 or 6 weeks.
Also, not quite correct about the online stuff. Online index rebuilds will, in fact, be online except for a brief bit at the very beginning and the very end of a REBUILD. At least that's what Paul Randal states. If you can prove something to the contrary, then I'm all ears because I'm all for destroying myths and certain practices that have been labeled a "Best Practice" when they're really not.
Nice on the tests, wish I could tell third parties to sort their indexes out and leave it to the DB's, not much chance of that though.
I have just looked around for where I read it and can't currently find it, but it made an impression when I did. I remember it stating that using online would attempt to build the index online and if it couldn't, then would build it offline instead. I may be totally wrong and imagining things though. If I find it, I will let you know. 🙂
April 25, 2018 at 5:28 pm
Anyone in England, how could one trace back relatives that emigrated to the US in the late 1800's or early 1900's?
April 26, 2018 at 1:24 am
Lynn Pettis - Wednesday, April 25, 2018 5:28 PMAnyone in England, how could one trace back relatives that emigrated to the US in the late 1800's or early 1900's?
Lynn, I know someone from Texas who traced his relatives back to a Scottish village, specifically this area.
If I can track him down (he relocated to the gentleman-friendly Philippines and defriended almost everybody, including me) I'll ask. He too is a former marine which may make things easier.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
April 26, 2018 at 7:07 am
check out http://www.werelate.org, genealogy wiki site, someone may have info posted or be able to help. Also, Janet Ariciu was a major part of my finding information, she does research for other people who need help (for a fee) but may also be willing to point you to resources (http://www.geocities.ws/janet_ariciu/ ). Lastly, there is probably a genealogical society near you that may have folks who want to help. Here's a BBC article with some UK references that might be useful. http://www.bbc.co.uk/history/familyhistory/get_started/paying_for_research_01.shtml
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
April 26, 2018 at 7:43 am
Haha!! I can post in the topic again! (Only took 4 hours of trying...)
Lynn, in the UK wWe do a Concensus every 10 years. If you're looking for data that old, then it'll be publically available now (1911 and prior are available). This might give you some help: http://www.nationalarchives.gov.uk/help-with-your-research/research-guides/census-records/
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
April 26, 2018 at 8:57 pm
FWIW, SO recognizes some problems: https://stackoverflow.blog/2018/04/26/stack-overflow-isnt-very-welcoming-its-time-for-that-to-change/#.WuIwkcIW6k0.twitter
I'd like to think that we don't do too much of this. I know a few people push the envelope, and some of us do at times (even me), but overall we do help and welcome newbies.
Viewing 15 posts - 61,441 through 61,455 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply