February 10, 2017 at 4:26 pm
Luis Cazares - Friday, February 10, 2017 12:37 PMIs a 200GB storage or less common for productive db servers? I know that I have a lot more in my laptops which obviously use cheaper storage, but it doesn't seem right to have such a limited space as the thread that wants to free 6GB of space because they run out of disk (and it's not the first time I see a thread like that).
It also didn't help that he was such an arrogant sot.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 10, 2017 at 5:14 pm
With virtualized servers, less than 200 GB is not uncommon. We tend to carve a bunch of little boxes in VM's as opposed to the big monsters.
And he was an arrogant sot!
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
February 11, 2017 at 1:40 pm
I am shocked at how many people are still creating new applications in VB6, Delphi, VFP and classic ASP.
What would you suggest them to use?
Something which could compile a code executable on any machine with any version of OS installed?
And not dependable on a correct version of .net framework installed across the board?
Which continuously needs fixes to its security vulnerabilities.
Not to mention licensing.
You know, a nail gun is so much more advanced comparing to a hammer.
But you'd be amazed, how many even professional builders use hammers on a daily basis.
Not to mention DIY'ers.
_____________
Code for TallyGenerator
February 11, 2017 at 5:17 pm
Michael L John - Friday, February 10, 2017 5:14 PMWith virtualized servers, less than 200 GB is not uncommon. We tend to carve a bunch of little boxes in VM's as opposed to the big monsters. And he was an arrogant sot!
Understood but for a busy 3TB box? I'm thinking that 128GB just isn't big enough especially since they have some serious hairball code that has caused 8 TemDB files to grow to 32GB. Remember that things in TempDB (including table variables) start off in memory.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2017 at 5:21 pm
Sean Lange - Friday, February 10, 2017 1:16 PMFor that matter I am shocked at how many people are still creating new applications in VB6, Delphi, VFP and classic ASP.
I'm still shocked at how many people are using all manner of code instead of T-SQL to talk to the database. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2017 at 7:14 pm
Jeff Moden - Saturday, February 11, 2017 5:17 PMMichael L John - Friday, February 10, 2017 5:14 PMWith virtualized servers, less than 200 GB is not uncommon. We tend to carve a bunch of little boxes in VM's as opposed to the big monsters. And he was an arrogant sot!Understood but for a busy 3TB box? I'm thinking that 128GB just isn't big enough especially since they have some serious hairball code that has caused 8 TemDB files to grow to 32GB. Remember that things in TempDB (including table variables) start off in memory.
I agree. Their box was not very well planned. I certainly have had to run servers "lean" for various reasons. But this sure seemed like poor planning.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
February 12, 2017 at 3:41 am
Jeff Moden - Saturday, February 11, 2017 5:17 PMRemember that things in TempDB (including table variables) start off in memory.
Please allow me to rephrase.
Remember that things in tempdb (including table variables), just like things in all other databases, are also stored in memory (the buffer pool).
The two reasons for my clarification are:
1. Your text suggests that tempdb is special, it is not (at least not in this regards)
2. Your text can be interpreted as if things do not take any disk space when they "start in memory"; this is not the case. They are not materialized on disk until a checkpoint occurs, but the space is reserved on allocation.
February 12, 2017 at 10:54 am
Hugo Kornelis - Sunday, February 12, 2017 3:41 AMJeff Moden - Saturday, February 11, 2017 5:17 PMRemember that things in TempDB (including table variables) start off in memory.Please allow me to rephrase.
Remember that things in tempdb (including table variables), just like things in all other databases, are also stored in memory (the buffer pool).The two reasons for my clarification are:
1. Your text suggests that tempdb is special, it is not (at least not in this regards)
2. Your text can be interpreted as if things do not take any disk space when they "start in memory"; this is not the case. They are not materialized on disk until a checkpoint occurs, but the space is reserved on allocation.
Thanks for the clarification but I was only talking about and trying to make a point only about the apparent problem with TempDB.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 13, 2017 at 3:44 am
I see the schedule for SQL Bits has been published. Some familiar Threadizen names on there...
SQL Bits Friday
SQL Bits Saturday
Rodders...
February 13, 2017 at 4:07 am
rodjkidd - Monday, February 13, 2017 3:44 AMI see the schedule for SQL Bits has been published. Some familiar Threadizen names on there...SQL Bits Friday
SQL Bits SaturdayRodders...
YES ! Can't wait!!!
February 13, 2017 at 5:56 am
Luis Cazares - Friday, February 10, 2017 12:37 PMIs a 200GB storage or less common for productive db servers? I know that I have a lot more in my laptops which obviously use cheaper storage, but it doesn't seem right to have such a limited space as the thread that wants to free 6GB of space because they run out of disk (and it's not the first time I see a thread like that).
It can be, depending on how many databases and what sizes they are. For a while in my workplace, 200 GB was the max on one server. Then we needed Other Things, so suddenly we had to add more DBs and account for growth on our 26GB database that was going to be more exponential than geometric, so now we don't have that small of a drive except on some log file only drives.
February 13, 2017 at 5:58 am
Jeff Moden - Saturday, February 11, 2017 5:21 PMSean Lange - Friday, February 10, 2017 1:16 PMFor that matter I am shocked at how many people are still creating new applications in VB6, Delphi, VFP and classic ASP.I'm still shocked at how many people are using all manner of code instead of T-SQL to talk to the database. 😉
Hey, I keep trying to talk English to my databases.
Of course, the "code" I use half the time isn't exactly "polite company" code and the databases continue to ignore me...
February 13, 2017 at 6:00 am
rodjkidd - Monday, February 13, 2017 3:44 AMI see the schedule for SQL Bits has been published. Some familiar Threadizen names on there...SQL Bits Friday
SQL Bits SaturdayRodders...
WHOOP! Two sessions this year, plus we'll be doing one for SQL Clone. I'm very excited about Bits, as usual. What is the theme this year?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 13, 2017 at 6:10 am
Grant Fritchey - Monday, February 13, 2017 6:00 AMWHOOP! Two sessions this year, plus we'll be doing one for SQL Clone. I'm very excited about Bits, as usual. What is the theme this year?
One session, but it's a double-length and it's one I've presented before so minimal work needed (just need to cram some Columnstores in).
I think the theme is "Disco", but haven't seen anything official.
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
February 13, 2017 at 6:46 am
Luis Cazares - Friday, February 10, 2017 12:37 PMIs a 200GB storage or less common for productive db servers? I know that I have a lot more in my laptops which obviously use cheaper storage, but it doesn't seem right to have such a limited space as the thread that wants to free 6GB of space because they run out of disk (and it's not the first time I see a thread like that).
I had to kick and fuss not too long ago to get our VMware team to give me bigger drives on my new servers. They'd been delivering with 40GB drives for the OS, and had a small snit fit when I requested 80GB OS drives + ~500GB data drives and 200GB Log drives, stating that I was only using ~2-300GB on the data side. My reply (respectful of course) was the OS itself took up nearly the entire 40GB then add in the bloody uninstall information for all the OS updates plus the updates themselves (all of which either go into a special folder you can't find without days of Google, or can't just go in and delete and instead have to ENABLE OS features that shouldn't be enabled on a server that doesn't need them to get the one d**ned tool that CAN remove the uninstall files for the updates but then ends up requiring yet MORE updates) on top of the fact that a database does one thing. It grows. And most of our customers do data loads on the weekends, when no one is here including the VMware team so who would be available in the event of an emergency need to grow a disk?
Yeah, the growth should be planned for, but sometimes you get that one boneheaded customer that manages to grow their TLog or database beyond all rational bounds when no one is looking and by the time you get the disk space alert the drive is full and everything stops...
Whoo.
OK, rant off.
Viewing 15 posts - 57,436 through 57,450 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply