Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
Hi All Хочется узнать Ваше мнение по поводу работы с 2000 SQL именно тех, кто реально с ним работает, и использует его. Как он в плане надежности, стабильности. Какие вдруг неожиданные глюки повылазили в процессе работы... Вообщем интересует мнение. Я собираюсь на него переходить, но вдруг что глобально глюкнет.. и что делать. вообщем буду рад услышать Ваши истории при переходе и работе на этом чуде... заранее Спасибо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2001, 11:59 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
Не боися. Отлично все работет. Проблема при переносе 7.0 -> 2000 только одна: в mssql2000 больше нет поля suid и функций SUSER_NAME и SUSER_ID. Если в базе такое используется, надо подправить заблаговременно, заменив соответственно на sid, SUSER_SNAME и SUSER_SID. После переноса, возможно, падет производительность. Тогда надо изменить индексную политику, так как в MSSQL2000 другой оптимизатор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2001, 10:31 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
Хочу уточнить. Глюки есть, но они, в основном, касаются новых возможностей этой версии (в частности, могут срабатывать instaed-триггеры, прикрученные к представлению). Внутри UDF тоже иногда творятся чудеса. А в плане того, что было в версии 7.0 - дополнительных глюков не замечено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2001, 11:10 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
А поточнее насчет UDF что за странности вкратце, что за глюки наблюдались, UDF это 2я причина по которой переходим на 2000 1я это скорость работы хотя текущая почти устраивает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2001, 16:02 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
>надо изменить индексную политику, так как в MSSQL2000 другой оптимизатор. у меня наоборот все работает на столько быстро, что я перехожу на него я до сих пор сижу на 6.5 просто потому что все работает и я его не трогаю иногда функция которая в 6.5 работала 30 секунд в 2000 работает за 1-2 секунды иногда конечно наоборот, но всего в пару случаев из всех и просто удобней работать чем в 6.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2001, 16:07 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
Сорри, опечатка. Не "могут срабатывать", а могут "НЕ срабатывать". Я на этой конференции сообщал уже о глюке внутри UDF. Проявляется он нестабильно. Выражается в том, что System_user вдруг ни с того ни с сего возвращает имя пользователя ВНУТРИ UDF в виде DOMAIN\USERNAME, хотя я залогинился через sa. Вне UDF такого не случается - всегда возвращает sa. Предупреждаю, что данный глюк был замечен мной, другими участниками данной конференции не подтвержден. От Деда Маздая поступило подтверждение на глюк с Instaed-триггерами. На самом деле он тоже проявляется нестабильно. При установке SQL-сервера с другого дистрибутива (взял у знакомого) глюк внезапно пропал. Возможно, это подправленный дистрибутив. А, возможно, глюк еще появится. И еще замечание. На использование операций внутри UDF налагаются весьма жесткие ограничения, которые ни в какое сравнение не идут на ограничения на команды внутри триггера или хранимой процедуре. Надеюсь, ты с ними уже знаком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2001, 19:05 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
A ISNULL with OUTER JOIN with VIEW? Why ISNUMERIC retirns 1 on NULL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2001, 20:04 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
To Garya: "А в плане того, что было в версии 7.0 - дополнительных глюков не замечено" Есть такой глюк http://support.microsoft.com/support/kb/articles/Q274/3/29.ASP?LN=EN-US&SD=gn&FR=0&qry=long%20time%20compiling&rnk=1&src=DHCS_MSPSS_gn_SRCH&SPR=SQL Он при переводе на 2000 рабочих баз попортил много нервов. Есть и много других ошибок, я где-то на МС сайте читал список. К сожалению, фиксы до появления СП доступны только за деньги. Бесплатно - только фиксы секюрити. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2001, 16:32 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
2 Vadim. Этот баг есть в перечне MS. Не охота искать, но насколько я помню, он был и в 7.0. 2 Alexeyvg. Это не так страшно как кажется. Если речь идет о VIEW и SP, то у них план строится один раз при компиляции. Можно разик и подождать. А вообще как раз в 2000 появился мощный инструмент против тормознутости сложных VIEW - материализация запросов. Лично я возлагаю большие надежды на эту фичу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2001, 17:45 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
Пожалуйста - переведите мне на английский термины "материализация запросов" и "материализованные представления". Что-то я часто их встречаю, но никак не могу понять об чем это, где почитать в BOL. Заранее благодарен С приветом Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2001, 09:27 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
2 Garya: А на чем основано утверждение, что план VIEW строится один раз при компиляции? Я считал, что MSSQL строит план выполнения запроса с VIEW и, соответственно, самого VIEW в контексте запроса (т.е. VIEW рассматривается оптимизатором как подзапрос). Или я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2001, 10:01 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
2SergSuper. Материализация запросов - это создание кластерного индекса по View. При его создании возникают данные (в самом кластерном индексе), которые отображает VIEW. Если выборка VIEW занимает много времени, то материализация - очень эффективный прием. Правда, он приводит к дублированию данных в БД и как следствие увеличению ее объема. Но положительно сказывается на скорости выборки. 2Павел. Просто вычитал в книжке (к сожалению, источник помню смутно). Насколько мне известно, при построении планов запросов, использующих уже откомпилированные запросы, используются планы уже откомпилированных запросов без их повторной компиляции. А иначе какой смысл в компиляции запросов и хранении VIEW на сервере, ежели бы они компилировались при каждом вызове? Может, я и ошибаюсь. Пусть тогда гуру поправят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2001, 22:50 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
Ну вот - провел я тут выходные перетаскивая базу с 7 на 2000 - завтра вечером поделюсь впечатлениями - если не уволят. Пока могу сказать следующее: 1. Collations - натрахался порядочно, так default collation отличался от collation восстановленной из семерочного бэкапа базы - трах тот еще, хотя "лавры" стоит разделить 50 на 50 между бестолковым мной и SQL Server'ом. Проблема в том, что временные таблицы создаются с default collation и построить потом join с обычными не выходит (если join по char/varchar полю). Есть какая-то опция для преодоления этого - но приложение готовое и не мое - так что не исправишь, тем более за один вечер. Ну ручками и скриптами изменил collation для примерно 500 полей - то еще удовольствие. 2. Нашлась совершенно кривая процедура, которую 2000 даже компилить не захотел, на семерке она работала как часы - но повторяю - кривая она до нельзя - например встречается такой код: WHERE ... ('SomeText'=1362). Вобщем о типах данных авторы не сильно волновались - но, повторяю, на семерке работала. 3. Производительнось - после исправления эта процедура все-равно работала на 8-процессорном сервере с 8 GB RAM, в ТРИ раза медленнее, чем на старом сервере с 4 CPU, 4 GB RAM под семеркой. Дисковые системы на серверах одинаковые, индексы под 2000 перестроил и статистику обновил. Не очень меня это воодушевило - посмотрим что утром будет, когда минимум 1000 человек на него упадет. 4. Ну DBCC на ЫЙД 2K, конечно, несравнимо быстрее работает - только это мне приятно, а юзерам по барабану... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2001, 23:17 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
ЫЙД 2K = SQL 2K. А вообще авторов этой базы (которую я перетаскивал) я бы просто убил - что-такое индексы, особенно кластерные, они точно не знали ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2001, 23:22 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
Вот - налетел - см. статью в Knowledge Base Q223423 - блин вместо индексов, кажый раз сервер сканирует 7 000 000 записей - исправить процедуру никакой возможности нет - юзеры не пускают, т.е. просто раком сервер стоит весь день... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2001, 19:00 |
|
||
|
Вернемся к MSSQL 2000
|
|||
|---|---|---|---|
|
#18+
Насчет многопроцессорности... Coast of parallelism крутил? Сравни эти параметры на 7.0 и 2000. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2001, 19:14 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=32005359&tid=1826833]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
26ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 344ms |
| 0 / 0 |
