December 11, 2010 at 2:31 am
If shrink should be available? Of course it should! There are situations where you need to have a tool to help you out. If any user decides to use it on a regular basis it is his responsibility and he should RTFM.
December 11, 2010 at 2:24 pm
Remove autoshrink? No... I never use it and probably never will. I also can't think of a reason why I'd ever use it. But it takes MS time to remove features just like it takes time for them to add them. MS should concentrate on doing more useful things.
Make any of the DBCC functionality more difficult to use? Heh... no way!
Leave these things alone. I use DBCC Shrinkfile and the like to get a whole lot of people out of trouble like when someone has been running databases for 5 years with FULL recovery mode and NEVER doing a transaction log backup. I don't care how good the advice of "never" shrinking a file is, you just have to love it when you can recover 4.6 TeraBytes (no... I didn't mispell that) on an almost full 10 TeraByte system in less than 20 minutes. 😉
Making things more difficult to use is fixing the wrong problem. It's kind of like saying that no one can drive on a Friday night because there are too many stupid people who drive drunk on Friday nights... it's "fixing" the wrong bloody problem. 😉
--Jeff Moden
December 13, 2010 at 6:01 am
dfalso (12/10/2010)
3. The downside to Simple recovery model involves backup tools that want to read the transaction log and create diffs. Ours, for instance. Since I keep everything Simple, it ends up having to do a complete backup. This is a conscious tradeoff as tapes are cheaper than disk, but it's something to consider.-Dom
If I remember correctly, Differential backups shouldn't require the transaction log at all, as they are done by backing up all of the changed extents since the last full backup, not the data from the transaction logs. That said, if someone told me a 3rd party backup app still wanted to see the transaction logs it wouldn't surprise me.
December 13, 2010 at 6:44 am
It's backing up the changed extents, but like full backups it'll need enough of the tran log to ensure a consistent restore, however I don't think dfalso was talking about SQL diff backups, but more like a 3rd party tool that creates a list of changes (diffs) by reading the transaction log.
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
December 13, 2010 at 7:14 am
Jeff Moden (12/11/2010)
MS should concentrate on doing more useful things..... Make any of the DBCC functionality more difficult to use? Heh... no way!
Leave these things alone.
... it's "fixing" the wrong bloody problem. 😉
Jeff, Glad to see youre comments. I always enjoy them.
I think most of us agree that fixing the buggy utility with code changes and better documentation is the real way to resolve these problems with any software project.
Why do you think M$ not taking this approach?
Why did M$ decide that removing (sometimes without depricating) and then hiding (sometimes retarding) administrative functionality in SQL server was the path to resolving customer issues?
My best guess: Fixing something that is broken requires skilled resources with real knowledge about developing a solution for an application issue. Removing it only requires removing the code and removing the documentation of the procedure.
For example: The resolution for fixing customers issues with the truncate transaction log utility in the BACKUP LOG utility was to remove the ability and let the community find another way to do this. Unfortuantely the "new way" requires make a change to the actual database settings that requires a change control. Running the SQL Backup utilities did not. So now when the Tran Log backups fail due to a weekend long SAN or Backup device issue (someone didn't change a tape) it takes two production DB updates to do what a one line backup log script and re-run of the last full backup to resolve.
This method of resolution by management instead of development is currently a serious desease killing features instead of making them better. I feel lucky to curretly work somewhere that feels like I do about this.
December 13, 2010 at 7:40 am
GilaMonster (12/13/2010)
It's backing up the changed extents, but like full backups it'll need enough of the tran log to ensure a consistent restore, however I don't think dfalso was talking about SQL diff backups, but more like a 3rd party tool that creates a list of changes (diffs) by reading the transaction log.
Yes, that. Thanks for clarifying.
December 13, 2010 at 12:55 pm
SanDroid (12/13/2010)
Jeff Moden (12/11/2010)
MS should concentrate on doing more useful things..... Make any of the DBCC functionality more difficult to use? Heh... no way!
Leave these things alone.
... it's "fixing" the wrong bloody problem. 😉
Jeff, Glad to see youre comments. I always enjoy them.
I think most of us agree that fixing the buggy utility with code changes and better documentation is the real way to resolve these problems with any software project.
Why do you think M$ not taking this approach?
Why did M$ decide that removing (sometimes without depricating) and then hiding (sometimes retarding) administrative functionality in SQL server was the path to resolving customer issues?
My best guess: Fixing something that is broken requires skilled resources with real knowledge about developing a solution for an application issue. Removing it only requires removing the code and removing the documentation of the procedure.
For example: The resolution for fixing customers issues with the truncate transaction log utility in the BACKUP LOG utility was to remove the ability and let the community find another way to do this. Unfortuantely the "new way" requires make a change to the actual database settings that requires a change control. Running the SQL Backup utilities did not. So now when the Tran Log backups fail due to a weekend long SAN or Backup device issue (someone didn't change a tape) it takes two production DB updates to do what a one line backup log script and re-run of the last full backup to resolve.
This method of resolution by management instead of development is currently a serious desease killing features instead of making them better. I feel lucky to curretly work somewhere that feels like I do about this.
I agree. Just "leaving things alone" is sometimes viewed by short-sided management as the easiest and most cost-effective approach, but in the long run,not always the smartest in software development, particularly, in this age of stiff competition. If fixing the problem means restricting or redesigning the functionality of a component that currently has undesirable side-effects, then that has to be considered sooner or later. Just ignoring or removing it and moving on to "other things" is kind of like ignoring the one loose nut on a rear tire. Yes, you can probably do that for a long while and get away it. But sooner or later it will come off when the car is doing 70 miles an hour and end up doing serious demage to something or someone else. Removing a feature really depends on what the feature is and where it is at. Ignoring this same feature that has undesirable side-effects is never a good idea in the long run IMHO. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
December 13, 2010 at 1:23 pm
TravisDBA (12/13/2010)
SanDroid (12/13/2010)
Fixing something that is broken requires skilled resources with real knowledge about developing a solution for an application issue. Removing it only requires removing the code and removing the documentation of the procedure.
This method of resolution by management instead of development is currently a serious desease killing features instead of making them better. I feel lucky to curretly work somewhere that feels like I do about this.
I agree. Just "leaving things alone" is sometimes viewed by short-sided management as the easiest and most cost-effective approach, but in the long run,not always the smartest in software development, particularly, in this age of stiff competition.
I would not prefer the complete removal of a 15 years old administrative utility over leaving it alone.
I prefer leaving things alone, or replacing them with a better working variation, over the 3D process known as degregate, depricate, and delete.
December 14, 2010 at 2:25 pm
Don't remove it - improve it! We use it quite a lot (unfortunately). I work in a business where there is a lot of manipulation of data which along with archiving leaves lots of free space. We frequently can have databases increase 50 - 100 GB in one operation only to end up with only 1 - 5 GB of that used. Leaving the space for the next operation isn't possible because that could be a once a year action. I have one database that when the archiving is fixed will have about 150 GB of unused space. Should I just leave that reserved by that database and not usable by any other one? I can't afford to have 150 GB of drive space become unusable, so I shrink the database.
Our databases get reindexed (defragged or rebuilt) based on their fragmentation. So that helps counter part of the issue caused by shrinking the database.
-SQLBill
December 16, 2010 at 4:49 pm
I like it as is. There are purposes for shrinking. It is easy to do. It is a well-known fact that shrinking a database hurts performance. What more can you ask for.
Jamie
December 16, 2010 at 4:55 pm
Jamie Longstreet-481950 (12/16/2010)
I like it as is. There are purposes for shrinking. It is easy to do. It is a well-known fact that shrinking a database hurts performance. What more can you ask for.
You mean like it is well know that you don't need to include both the index rebuild and index reorganize steps in your maintenance plans? 🙂
December 16, 2010 at 4:58 pm
Correct. It is fairly common for someone to advise me to add shrink to my plan but it seems to me unnecessary and what I've read indicates I'm right. I'm okay with that. Yes. Microsoft software tends to assume we are all stupid. In this case, they assume differently. I like that.
Jamie
Viewing 12 posts - 61 through 71 (of 71 total)
You must be logged in to reply to this topic. Login to reply