Назад | Перейти на главную страницу

Каковы причины по-прежнему использовать SQL Server 2000?

Из вопросов о StackOverflow и других источниках я заметил, что все еще есть люди, использующие SQL Server 2000. Если честно, на меня больше всего повлияло то, что я должен вспомнить, как мы привыкли делать что-то без общих табличных выражений.

Тем не менее, я хотел бы знать, есть ли реальные причины (помимо «он не сломан») по-прежнему использовать SQL Server 2000. Например, я знаю, что есть люди, которым приходится использовать .NET 1.1, потому что они должны поддерживать Системы Windows 2000. Есть ли аналогичные практические причины не обновлять систему SQL Server 2000 до SQL Server 2008 или 2005?

Деловой ум обычно сильно отличается от вашего. Зачем использовать что-то новое, если это не принесет больше дохода, а принесет только расходы (миграция, переподготовка и т. Д.)?

Лучшая причина, которую я могу придумать, - это вариант выражения «это не сломано», который звучит примерно так: у вас есть бизнес-приложение, которое работает с SQL 2000, но генерирует ошибки с SQL 2005. Это может быть неправильным приоритетом бизнеса для вашей организации на этот раз, чтобы открыть капот этого приложения (которое не сломано) и заставить его работать с более новой базой данных.

Поддержка старых версий

SQL Server 2005 не полностью обратно совместим с SQL Server 2000. Службы Analysis Services имеют серьезные несовместимости. Переход на SQL Server 2005 требует ненулевых затрат на регрессионное тестирование и перенос. Многим организациям не требуется переезжать, поэтому они не переедут, пока не будут вынуждены.

Большинство поставщиков СУБД (включая MS) будут поддерживать версию СУБД в течение 10 лет или около того, что дольше, чем у большинства других типов программного обеспечения. Если вы скрестите их ладони с серебром (в достаточном количестве), они также заключат определенные контракты, чтобы продлить поддержку конкретной версии на более длительный срок.

Другие причины придерживаться более старых версий действительно обусловлены конкретными обстоятельствами, такими как отказ от известных неудачных выпусков (например, MySQL 5.1 или SQL2000 до SP3) или проблемы с сертификацией или совместимостью.

Обслуживание производственной базы данных SQL Server 2000

Для операционной системы, которая работает и находится на зрелой фазе своего жизненного цикла без значительных изменений, вероятно, нет веских причин для обновления до того, как СУБД выйдет из основной поддержки. Тем не менее, вы должны спланировать упорядоченный путь обновления на этот случай. Oracle известна людьми, поддерживающими производственные системы на старых версиях.

Срок службы SQL Server 2000 приближается к концу, поэтому вам не хотелось бы проводить над ним новые разработки. Тем не менее, производственное приложение следует поддерживать с планом выхода, когда вам нужно. Если ваше приложение написано на VB6 или классическом ASP, вам, вероятно, придется его переписать, но это уже другая проблема; -}.

Встречный случай

Если бы у меня был проект с нуля, я бы обычно рекомендовал последнюю версию платформы СУБД просто потому, что она дает вам самый длинный период поддержки со стороны поставщика. Ни у кого не должно быть SQL Server 2000 в качестве корпоративного стандарта для новых проектов - EOL слишком близок. Для нового проекта это, безусловно, самый сильный аргумент в пользу перехода на более новую версию. Аргументы об экономии денег не выдерживают критики; если вы начнете использовать SQL2000 сейчас, приложение будет нести ненужные затраты на перенос в течение пары лет.

Ключевым моментом для работы с нуля является то, что чрезмерно консервативный выбор сокращает срок службы приложения до того, как потребуется обновление. Обычно требуется конкретная причина не использовать текущую версию платформы СУБД.

Мы не обновляемся, потому что у нас есть финансовое программное обеспечение, которое полагается на него, а поставщик только думает о поддержке этого нового «SQL 2005», о котором в последнее время слышали в блогах безумных детей.

Честно говоря, это больно меня иметь смесь вещей, которые нужно поддерживать, но не так сильно, как это могло бы повредить все в компании чтобы всплывала проблема с финансовой системой, а затем продавец финансового программного обеспечения указывал на нас и смеялся, когда мы просили о помощи и упоминали, что проблемы начались с того момента, как мы обновили SQL 2005 до того, как они его ратифицировали.

Также можно многое сказать о том, чтобы не ремонтировать вещи, если они на самом деле не сломаны. Я действительно хочу когда-нибудь обновить все свои SQL-серверы до 2008 ... Я действительно хочу. Но я мог бы делать гораздо больше вещей, которые на самом деле улучшают чистую прибыль бизнеса способами, понятными и поддающимися количественной оценке для моих менеджеров и пользователей ... ну, это всегда будет на первом месте.

Вы упоминаете разработчиков, которым не нравится работать с SQL 2000, в своем ответе на ответ Mastermind. Я подозреваю, что одним из способов справиться с этим будет тот, который мои боссы применили бы ко мне, если бы я решил, что мне «не нравится» поддержка SQL 2000: «Спасибо за время, проведенное здесь, дверь слева от вас». В конце концов, нам всем платят за то, чтобы все работало, нравится нам это или нет.

В нашем случае это не столько вопрос «зачем продолжать использовать 2000», сколько вопрос «СКОЛЬКО стоит обновление?». Большинство наших приложений не используют ничего, что требует каких-либо специфических для 2005 года функций, поэтому веских причин нет и, вероятно, не будет, пока Microsoft не прекратит поддержку этого.

Стоимость.

Новое программное обеспечение по-прежнему является дополнительным программным обеспечением, которое требует дополнительных денег.

Это может быть и часто является ложной экономией из-за множества недостатков использования устаревших систем, но это единственная реальная причина, которая имеет смысл.

Новая лицензия на SQL Server 2008 (стандартная) стоит немногим менее 2000 долларов за 1 сервер с 5 клиентскими лицензиями или 6000 долларов за 1 лицензию на ЦП. Я слышу, как мой старый босс говорит: «Он не сломан, но сколько будет стоить обновление этих двух серверов?» (в то время два двухпроцессорных процессора, требующие лицензий на ЦП).

Я использовал SQL2000 в течение семи лет, и в 2005 году я впервые столкнулся с окружением VMWare ESX. Отстойная производительность (провайдер предоставлял опыт VMWare, и когда мы начали нагрузочное тестирование, мы обнаружили, что у них были серьезные проблемы не только с нашим сервером, но и на наш опыт), и в сочетании со всем, что перемещалось / переименовывалось (старый менеджер предприятия был ооочень намного быстрее) - мы с радостью отложили обновление. Затем мы ждали выпуска 2008 года, поэтому мы только сейчас обновляем до 2008 года (или переносим некоторые данные в MySQL / PostgresSQL).

Microsoft по-прежнему предоставляла основную поддержку для 2000 года до некоторого времени в прошлом году, поэтому только недавно у нас появилась более веская причина для обновления.

У небольших компаний также есть проблема с ресурсами - обучение, планирование, тестирование обновления требует времени и влияет на другие операции. Если вам нужно обновить какое-то другое приложение, которое одновременно находится на SQL Server, это тоже может стать очень дорогим.

Какое-то время мы флиртовали с переходом на открытый исходный код, и хотя это было возможно, оно также приостановило любое обновление.

Почему бы не перейти на sql server 2008, тогда вы действительно сможете снизить свои затраты за счет сжатия данных, упрощения обслуживания и повышения производительности (отфильтрованные индексы)? Недавно мы обновили установку sql server 2000 и сэкономили 75% дискового пространства, а производительность резко возросла.

Еще одним улучшением стал параллелизм благодаря новому механизму блокировки, представленному в sql server 2005.

/ Хокан Винтер

Крупные организации не склонны к риску и невежественны, что приводит к очень глупым решениям. Когда я занимался Unix примерно в 2003/2004 году, мы застряли в среде Solaris 2.5.1, которая была выпущена, когда я учился в 10 классе или около того, потому что это была «проверенная» технология и было «слишком дорого» для обновления.

Слишком дорого часто называют PHB: «Я был тупым, чтобы выделить 1000 долларов на апгрейд в 10-миллионном проекте».

В случае программного обеспечения стека Microsoft люди часто не хотят обновляться, потому что они не хотят иметь дело с лицензионным троллем внутри компании и приобрели лицензию OEM у Dell / IBM и т. Д., И не хотят иметь дело с бюрократические обручи, задействованные в модернизации.

Я не верю (каламбур) аргументу «предоплата», но, к сожалению, авансовые затраты - это то, чем одержимы многие PHB, поэтому допустимо оставить это в силе.

Для меня единственной веской причиной могут быть приложения, которые его используют. Например, если вы работаете с SharePoint 2003, вы НИКОГДА не собираетесь обновляться до SQL 2005 или 2008, не выполнив также обновление SharePoint, что нетривиально.

В нашей организации предполагается, что все новые разработки будут на базе SQL 2005/2008, но у нас так много устаревших приложений 2000, что просто не стоит тратить время / энергию / деньги на их преобразование.

В дополнение к проблемам совместимости (DTS для SSIS - самая большая проблема для нас), мы также реализовали набор руководящих принципов / ограничений безопасности для SQL 2005, которые мы не применяли для SQL 2000 (нет пользователей dbo, только разрешения схемы, и т.д.)

В нашей организации тому несколько причин. Некоторые из них довольно специфичны для нашего случая, а другие - более общие.

1) Несовместимость. У нас было несколько случаев, когда программное обеспечение, написанное собственными силами для SQL2005, имело проблемы при установке на SQL2000. Случай, который я видел совсем недавно, закончился тем, что были явно объявлены параметры, которых не было в 2000 году, и разница в имени таблицы системных индексов. (sys.indexes vs sysindexes)

2) Обучение. Наши разработчики наверняка знают 2005 год и предпочли бы развиваться на нем или уже на 2008 году. Однако работа по поддержанию всего работоспособности ложится на NOC, а не на разработчиков. Никто в нашем NOC не проходил формального обучения SQL, и различий между ними, просто с точки зрения административных инструментов, достаточно, чтобы принять это во внимание.

3) Стоимость обновления существующих продуктов. Для нас это очень важно. Я не говорю здесь о стоимости лицензии от Microsoft. В нашем бизнесе обновление любого из наших существующих продуктов (даже если мы не обновили задним числом все, что уже есть в полевых условиях) потребует дорогостоящего и длительного процесса повторной сертификации в нескольких различных нормативных и сертификационных испытательных лабораториях. Мы создаем новые продукты на базе SQL2005, но по этой причине не обновляем старые.

Процесс сертификации также означает, что мы получим смесь для новых сборок, где одни юрисдикции будут получать SQL2000, а другие получат SQL2005, в зависимости от того, были ли получены утверждения еще или нет. По причине № 2 мы предпочитаем, чтобы наша производственная среда была как можно более согласованной.

4) Общие отличия. Это действительно расширение №1. Изменилось множество мелких вещей, некоторые из которых вызывают у нас головную боль. Например, SQL2005 на Server2003 будет применять политики паролей Windows к учетным записям sql. Неплохая вещь сама по себе, но она ломает почти все наше (и многие сторонние) программы из-за того, как мы взаимодействуем с базой данных.

Одним словом, инерция.

А хороший пост в блоге который уже задавал тот же вопрос.

Я знаю, что есть люди, которым приходится использовать .NET 1.1, потому что они должны поддерживать системы Windows 2000.

Следуя этой логике, практическая причина для запуска MSSQL 2000 заключается в том, что вы можете поддерживать системы Windows NT 4!

Вы не поверите, но SQL Server 2005 на самом деле работает на Windows Server 2000.