Page 1 of 2 12 LastLast
Results 1 to 15 of 20

Thread: Upgrade

  1. #1
    Join Date
    Apr 2007
    Posts
    8

    Unanswered: Upgrade

    Hey guys - I need your help. We are using SQL Server 2000- do you think, we should upgrade to some later release of Microsoft SQL Server or Migrate to Oracle, IBM or Sybase. I am also wondering, what do you think of Open Source MySQL and PostgreSQL. Have anyone of you using these databases. Thanks guys for your help
    - Mark Smith

  2. #2
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    If you have existing applications, I would not be in a rush to upgrade to 2005.
    If you are planning new applications, then you will save yourself the trouble of a later upgrade if you start out with 2005.
    Oracle is a royal pain to administer and its SQL syntax is terrible. Stay away from it as a development platform.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  3. #3
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    You are unlikely to get many people saying "go for Oracle!" in a SQL Server forum.

    This is useful:
    http://rentacoder.com/CS/blogs/real_...04/28/477.aspx
    surmises many of the issue upgrading to 2005.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  4. #4
    Join Date
    Mar 2007
    Location
    Holmestrand, Norway
    Posts
    332
    Somebody shoot me, but when thinking of database servers, there are six coming into my mind: MySQL, PostgreSQL, DB2/UDB, Oracle, MSSQL and Sybase. I can see a market for everyone, that is at least partially for Sybase What you should go for is a matter of needs. What features do you need in the application? How many concurrent users are there? How complex data have you got. What platforms do you need to support? These are among the questions you got to ask yourself. THEN you may get an answer to your questions
    Ole Kristian Velstadbråten Bangås - Virinco - MSSQL.no - Facebook - Twitter

  5. #5
    Join Date
    Mar 2004
    Posts
    190
    MySQL and PostgreSQL are excellent products if you are familiar with unix and are heavy on scripting. I've never had any issues getting databases to work normally, or on their reliability as a whole. The problem comes when you want to do complex things, and you aren't 100% familiar with the product. There are a lot of places and forums to get help in those areas, so I wouldn't shy people away from it at all. The problem is also that most companies don't want to complicate their environment with yet another system. If you already have MSSQL server in your environment, and you have the people who know that system... I would be reluctant to change it.

    As for Oracle, it has it's good points. It seems to be less resource intense and it manages it's processes better than MSSQL. You need training for Oracle, and it's not a plug-and-play system like MSSQL can be. I know plenty of Network Admins who are running several different instances of MSSQL on different boxes for different applications without a DBA to keep track of everything. MSSQL simplifies things for the masses, and despite it's occasional security issues and patch problems, it's a good system.

    I agree with blindman in saying that if you are developing something new and are going the MSSQL route, go ahead and develop it on MSSQL 2005. You will be better off in the long run.
    "An adventure is only an inconvenience rightly understood; an inconvenience is only an adventure wrongly considered." ~G.K. Chesterton

  6. #6
    Join Date
    Dec 2002
    Posts
    1,245
    We're in the process of migrating our apps to SQL 2005. We're doing it in a phased, parallel approach making use of the backwards compatibility mode in SQL 2005 (run the database just as if it were on a SQL 2000 platform).

    So far, the only issue we have encountered is the need to upgrade the JDBC drivers on the clients (why JDBC in a SQL environment? please; don't ask). The old version (1.0?) is not compatible with SQL 2005 and will throw an error.

    Regards,

    hmscott
    Have you hugged your backup today?

  7. #7
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Quote Originally Posted by msmeland
    As for Oracle, it has it's good points. It seems to be less resource intense and it manages it's processes better than MSSQL.
    Not in my experience. I can only speak to Oracle and SQL Server, not having used the other products extensively, but Oracle is not only much more difficult to administer, but it has a huge resource footprint and its SQL syntax is much slower and less efficent than SQL Server's for anything but the simplest SELECTS and INSERTS.
    When I quote for an Oracle job I figure out the hours that would be required to do it in SQL Server and then double the result. That has proven to be pretty accurate.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  8. #8
    Join Date
    Mar 2004
    Posts
    190
    I guess I haven't had the same experience. Perhaps it is how the programs are written and what's being called that ultimately determines how well the system runs. I have a program written with a MSSQL that dogs one of my newer servers with four processors and 16 GB of RAM. I have an identical server running some software that controls and monitors our reactors and tanks that is not nearly as resource intense. But when I loaded the two servers (one is Oracle and one is MSSQL) before the apps were in and online, Oracle was using a lot less resources to complete the same tasks. Patching Oracle can be a pain, and security is a hassle though so I do agree that administration can be a real mess and task intensive. If you can avoid Oracle, I would on that alone unless you are already an old hand.
    "An adventure is only an inconvenience rightly understood; an inconvenience is only an adventure wrongly considered." ~G.K. Chesterton

  9. #9
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Quote Originally Posted by msmeland
    I guess I haven't had the same experience. Perhaps it is how the programs are written and what's being called that ultimately determines how well the system runs.
    Ten minutes to execute SELECT COUNT(*) FROM [EMPTYTABLE] on Oracle. If you know of a way to make that code more efficient, please enlighten me.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  10. #10
    Join Date
    May 2005
    Location
    Nevada, USA
    Posts
    2,888
    Provided Answers: 6
    Something strangely familiar about this post:

    http://www.dbforums.com/showthread.php?t=1617526
    Paul

  11. #11
    Join Date
    Mar 2004
    Posts
    190
    Quote Originally Posted by blindman
    Ten minutes to execute SELECT COUNT(*) FROM [EMPTYTABLE] on Oracle. If you know of a way to make that code more efficient, please enlighten me.
    On my current Oracle server using SQL*Plus, executing that piece of code on an empty table I have that has 34 columns of varying sizes and types including an indexed primary key, it goes right through. I created a two column empty table with no index or primary key and ran it again with the same results.

    It could be a host of problems causing it to take ten minutes on your server. Database structure, indexes, configuration... I don't know and couldn't wager a guess nor would I without more information. What I do know is that not everyone experiences the same issues you are having. There are plenty of people who have no problems with Oracle at all. I personally prefer MSSQL or MySQL, but not everyone shares that opinion.
    "An adventure is only an inconvenience rightly understood; an inconvenience is only an adventure wrongly considered." ~G.K. Chesterton

  12. #12
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    The issue was most likely caused by a HWM (High Water Mark) with a table that had contained about 15000 rows prior to run a delete statement on it.

    So to simulate the issue you would need to populate a table, delete (not truncate) all the records, and then run your SELECT COUNT(*).

    I have run into this problem several times on several Oracle servers.

    I've spent all morning dealing with another Oracle query that would run with no problems on SQL server, but drags ass on Oracle. Had to stop it after 90 minutes. The Oracle PSQL syntax sucks for any queries of moderate complexity.

    Quote Originally Posted by msmeland
    There are plenty of people who have no problems with Oracle at all.
    Yes. Those would be the people who have never had to use it.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  13. #13
    Join Date
    May 2004
    Location
    Seattle
    Posts
    1,313
    only 15k rows initially and it took 10mins to return???

    I was thinking maybe 15m, or maybe 150m. I guess oracle does indeed suck hard in this respect.

    or were you using a walkman for a storage device?

  14. #14
    Join Date
    Nov 2005
    Posts
    122
    Quote Originally Posted by msmeland
    and despite it's occasional security issues and patch problems, it's a good system.
    There are NO security flaws on SQL Server 2005.

  15. #15
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by msmeland
    MySQL and PostgreSQL are excellent products if you are familiar with unix and are heavy on scripting.
    preposterous and outrageously inflammatory

    i couldn't spell cat in unix if you spotted me the c and the a, and yet i'm quite productive with mysql, and without ever having written a single line of script, too
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •