December 18, 2009 at 9:37 am
David.Poole (12/18/2009)
The article was mainly about standard edition.The killer feature for enterprise users is the ability to switch partitions on replicated tables. This means that with careful design the purge of millions of records can be achieved in the blink of an eye without thrashing the disks and transaction log.
that's our biggest problem
we have a database that is refreshed every 45 days on average. new data comes in every few days and old data is archived. some days the archive process deletes 50 million rows and it kills replication. tried a lot of things to avoid rerunning the snapshot but no luck
December 18, 2009 at 9:41 am
jts_2003 (12/18/2009)
I think with R2 just around the cormer, I'd wait for the first SP for that before upgrading. After all, will Microsoft release SPs and CUs for non R2 SQL Server 2008?
MS is still releasing CU's for SQl 2005 based on the code review of SQL 2008
December 18, 2009 at 10:49 am
sentiant (10/20/2008)
It sounds like M$ is giving us another hard boiled egg. I'm very disappointed in 2005 to begin with, as 2000 had features that aren't even native to 2005. For instance, Importing data was so much easier in 2000. Now all my DTS' are pretty much worthless unless I want to combine a 2000 package with the 2005 and then I still have to perform most of the work manually.I was also disappointed in your article. You basically gave us a short summary of whats new and whats lacking but couldn't deliver the money shot when it came to saying 2008 is garbage so don't get it.
I mean come on, you basically asked at the end of the article what we thought... Gee, When I read the title of the post in my email I thought you were gonna tell me what I clicked thru to find out.
I agree with the DTS problem.
I can copy a database in 2000 with 3 or 4 clicks.
To copy a database in 2008 is a real pain.
I develop Access .adp applications for our company.
I have created over 150 databases this year. Each one is similar but enough difference that one standard format can not be used.
We just changed from Access 2000 to Access 2007.
We currently use SQL Server 2000 as the back end.
SQL 2000 objects can be modifed from Access 2000 or Access 2007 but SQL 2008 objects can not be modifed.
I am afraid that Access 2010 is droppng the adp projects and enforcing ODBC.
That will require object changes in SQL server to be performed in management studio.
Oh well, in the meantime, we will stick with Office 2007 and SQL 2000 until such time we are forced to make a change.
"When in danger or in doubt. Run in circles, scream and shout!" TANSTAAFL
"Robert A. Heinlein"
December 18, 2009 at 12:01 pm
The behind the scenes optimizations that are out with SQL Server 2008 as well as the enhansements to SSIS, SSAS, SSRS development and T-SQL enhancements make it a no brainer to me. The development time saved is totally worth the investment! Testing and validating is also much quicker. If I want to test a bug in a procedure and need to create a working copy for debuging, I bring over the input variables add one simple declare, the guts of the procedure minus try catch blocks and begin debugging. Now, I do not have intellisense, I do not have the ability to add most of a procedure with only one or 2 lines. Now I have to declare every input variable and set every input variable instead of only changing the defaults on just one or 2 for testing. I have a SQL 2005 environment and a local environment of 2008 for debugging, my PM wants to know how I can find problems so quickly when others can't even get their working copy by the time I am finished. I am sorry, but I just think that with lots of complex mathmatical t-sql in my industry, it is far to much of a no brainer.
I also do not have to jump through hoops trying to build things in SSRS that are simply not available with SQL Server 2005.
All of that being said, THIS IS A FORUM, and everyone is entitled to their opinion. This is just mine and intended in no way to be offensive, derogatory, or pointed at anyone.
BE KEWL!
December 18, 2009 at 1:07 pm
We are currently upgrading from SQL Server 2005 to 2008. One major factor in our decision to upgrade was Filtered Indexes.
December 18, 2009 at 1:26 pm
chris.watson (12/18/2009)
Does any one have any experience in running integration services and reporting services under 2005 and upgrading to 2008 - are there bigger benefits here - I wonder as these 'extensions' do appear to be 'bolt-ons' to the core 2005 products and we are led to believe there is better functionality in the 2008 versions.
Here is a fairly in-depth article on the SQL Server 2008 BI improvements: SQL Server 2008 Business Intelligence Enhancements
December 18, 2009 at 1:45 pm
I absolutely believe it is useful to upgrade from SQL 2005 Standard to 2008 Standard. The warehouse I manage has gone from 7.0, 2000, 2005 to 2008. Going to 2005 was a lot of effort for the developers (because of lots of DTS and Analysis Services), but it made the upgrade to 2008 painless. We noticed an obvious difference in performance across many reports when we went to 2005. The change when we upgraded to 2008 was even more obvious. Same hardware. Still x86. Most reports use cubes as the source.
Building cubes in BDS is much nicer now, and Reporting Services 2008 is sweet. I love finally having a native Date type. Intellisense - have Red-Gate at work so don't need it there, but it's darn handy at home.
My comments are mostly subjective, but I can say unequivocally that those of us in my organisation, and at our vendor, are very pleased that we went to 2008. It didn't feel like a small change at all. Whereas 2000 to 2005 felt like we were rebuilding the engine (hard, dirty work), 2005 to 2008 felt like getting a tune-up, new tires and a paint job all in one.
December 18, 2009 at 1:57 pm
Too bad that backup compression is not in the Standard edition. But, if you're using the Standard edition, hopefully your databases are small enough that disk space for backups is relatively inexpensive.
We have some 230 GB SQL server databases, which are replicated to production, development, and QA environments. The development ones get changed sometimes, so these databases all get backed up.
Backup compression saves disk space, AND, what most people don't realize, is that it also takes less TIME to perform a compressed backup than an uncompressed backup. So, the backup is smaller, and the backup job runs faster too.
December 18, 2009 at 3:33 pm
Actually, backup compression was announced to be available in Standard Edition of SQL Server 2008 R2, when it is released. Apparently scheduled for sometime in 2010. (Just in case that matters to you.)
December 18, 2009 at 4:03 pm
That's good, if compression makes it into the standard edition. It will speed up backups for small businesses too. 🙂
December 18, 2009 at 9:59 pm
Please check the link given regarding differences between SQL Server 2005 and SQL Server 2008. The link doesnot exist.
December 18, 2009 at 10:33 pm
When the resource governer hits the standard edition we will be encouraged to move along.
DTS Minor Rant Warning:
BTW we still use DTS - despite having several books at work on SSIS that our key people have read at one point or another.
Thus far we have found DTS easier and more intuitive: SSIS takes a heap longer to achieve what comes intuitively in DTS, and this despite having no DTS documentation at all.
Why? Personal view - possibly a bit of a caricature but saying this to underscore a trend line not denigrate valid outliers - SSIS is in effect attempting to turn .NET application developers into DBAs raher than an attempt to provide a productivity framework that leverages the way DBAs handle data.
If I were to buy software from a sql focused company (e.g. RedGate) as a DBA I expect to be able to use their products directly - i.e. expect their software to enhance rapid-fire set based thinking out of the box - with no need to stop and translate anything into an alternate paradigm in order to "keep up" with the latest trends.
Personal view is .NET is coat-tailing the fundamental success of T-SQL rather than leavarging it by a demonstrable factor of "X". What I want is a product that delivers an "X" factor without having to change the way that I think - which is already carefully tuned around the foundational driver of T-SQL.
Are we squeezing DBA productivity through an unnecessary energy consuming vortex - in order to achieve a marketing target? Is there a productivity target? Solving pedantic application specific puzzles and side-isses does not add to my productivity as a DBA.
We are in the process of moving to a competitor to SSIS because we see MS taking the wrong fork in the road - DBAs should not have to leave a development environment in order to work in a foreign environment built for application development and then like the proverbial Humpty Dumpty, have to glue everything back together again better than new.
December 19, 2009 at 2:42 am
you are so right dude!
December 19, 2009 at 4:26 am
danschl (10/22/2008)
since there isnt going to be a sql2005 sp3sql2008 is actually that, so we arent upgrading to sql2008 from sql2005
but it there is a new server purchase it will probably be sql2008
Ermm there is a SQL 2005 SP3 and has been for some time...
AMO AMAS AMATIT AGAIN
December 19, 2009 at 8:20 am
Good reason to upgrade to SQL 2008 is if your company uses Office products 2007.
BI - Excel import export of data to 2007
..unless there is some add on driver I don't know about like
SSMA sql server migration assistant for access 2003 and 2007.
Excel 2007 - more then 65,000 rows, and business analytic tools(really just wizards, but make it fast if you know what you want)
The SSIS packages follow a stricter Development environment which I think can be good, but still has those wizards, there just in different places. Take the time to look for them.
And more importantly If not upgrading all servers, continue to upgrade a test environment , don't wait to fall back until your forced to upgrade and see a complete departure of what you are used too.;-)
Viewing 15 posts - 61 through 75 (of 89 total)
You must be logged in to reply to this topic. Login to reply