База на SQL 2000. Реиндексацию можно делать из конфигуратора или настраивать задания в SQL сервере.
Как правильнее? В чем различия?

Да всё вместе лучше. Сначала из конфигуратора, потом скулем.

В сиквеле наверное правильнее...

(0) (задумчиво) а чЁ хочешь получить в результате?

Только в SQL, хотя она особенно не нужна ему.

Реиндексация из 1С делается только с DBF версией

Виноват, не заметил, что это под 8.0

(3)Советуют реиндексировать базу раз в неделю, вот думаю как лучше.
(1)Времени будет много уходить

бухи задним числом работают

(7) "странный совет"... А про "статистику" у сиквела советники даже что? Не слышали?

(8) А чё странного? Кажись в "Профессиональной разработке..." об этом читал...

(8)Вот и хочется услышать совет спецов, нужно или не нужно, если нужно то как и как часто?
Надеюсь на помощь :)

(9)"Профессиональной разработке..." - недавно вышедшая книжка?

(11) ну уже не недавно, я бы сказал...

(12)а что там советуют? книжку купить пока не удалось

(9) У меня эта книга лежит на столе.. Дай ссылку ГДЕ про "реиндексацию раз в неделю" в ней написано? :-)

(10) понимаешь.. Нужно подходить не "догматически".. а понимая "что" и "для чего" нужно делать...

Для ЛЮБОЙ СБД "реиндексация" нужна только после массового "влива" информации.. А что? У тебя в 1С еженедельно "вливается" так много документов??? У тебя какой объём БД (и в гигах и в доках)?

(14) а у меня под рукой нету, так что утверждать не буду...

(14) ну если на столе, то стр. 724.
они даже в качестве примера предлагают каждый день делать

тынц
http://www.sql.ru/articles/mssql/03013101Indexes.shtml

(14) 3 Гиг, доков в пределах 30 тыс
первичка создается каждый рабочий день, бухи много правят задним числом

(16) вооот, я же помню что что-то такое читал...

(16) Ну-у-у.. "читаю"...

"Можно заметить, что после выполнения интенсивных операций по модификации данных..."

ключевая фраза "выполнения интенсивных операций по модификации данных"..

А где написано про "каждый день"?

(18) А причём тут "перепроведение"??? Речь идёт о ПЕРЕИМПОРТАХ... Перепроведение это только "перерасчёт".. Тут переиндексация - нИпоможет :-)

(17)Спасибо почитаю
(20)Т.е. если они в документе изменили сумму, то индексы не нарушаются
а если они вставляют доки или переносят на другие даты, тогда надо реиндексировать. Так?

(21) вопрос о МАССОВОСТИ этой вставки... Вот когда у меня импортом падало более 800 тыс записей, то подобное было актуально.. Я даже "грохал" перед импортом индексы и затем их создавал заново (не реиндексировал, а именно пересоздавал)..

а если "вводится" 0.0005% к существующим докам - то это "спички" и тут парится даже вредно :-)

(20) так про интенсивность никто и не спорит
ты читаешь, на стр. 723
а на стр. 724 написано "При высокой интенсивности операций модификации данных возможно использование комбинации этих методов: выполнение в течении рабочего дня дефрагментации индексов и выполнение переиндексации таблиц базы данных после окончания рабочего дня."
Т.е. при интенсивной нагрузке хоть каждый день

Какой размер БД?

(24) 3 Гиг
(All)
Ну хотябы раз в месяц нужно их делать?

(23) во-во.. опять же ЕСЛИ.. Это "условный оператор".. А давать "безусловно" такую рекомендацию - ГЛУПО :-)

Ещё раз... Ключевое слово "При высокой интенсивности операций модификации данных" ... И переиндексация делается ПОСЛЕ  ряда "дефрагментаций"...

кстати.. Если ты изначально "расширишь" экстенты, то необходимость в частой реиндексации опять таки "резко снизится"

(25) Да не размер тут влияет.. А РАЗМЕР и "волотильность" (насколько у тебя в процентах растёт база)... У тебя 3 гига - за какой период "образовалось"?

(0) sp_MSforeachtable "DBCC DBREINDEX ('?') WITH NO_INFOMSGS"

(27)Чуть меньше года (8-10 мес)

Зачем что то писать если все делается простым визардом?

(29) Ну и делай тогда "подобное" раз в квартал :-)

ЗЫ.. Но если тебя этот вопрос "мучает", то можно "смотреть" степень дефрагментированности индексов и принимать решение "по месту"

ЗЫ.. но для такого пилотажа нужно "курить" книги по SQL и по админству сиквела..

удачи

(26)как это "изначально "расширишь" экстенты"?
как их расширить и куда?

(32) читай http://www.sql.ru/articles/mssql/03013101Indexes.shtml

Особенно обрати внимание на:
17.1. Типы фрагментаций

Когда запись удаляется, в файле БД высвобождается место. Когда вставляется новая запись, это может привести к расщеплению страниц, что приводит к появлению пустого пространства на страницах данных. Когда данный обновляются, это может привести к изменению размера записи и к возникновению двух ранее упоминавшихся случаев. Все это приводит к фрагментации. В SQL Server рассматриваются два типа фрагментации: внутренняя и внешняя.

Внутренняя подразумевает пустоты внутри страницы. Внешняя – непоследовательность связей страниц.

Если страницы не полностью заполнены данными, это приводит к дополнительным операциям I/O и переиспользованью оперативной памяти. Помните что страницы в оперативной памяти есть зеркальное отражение страниц на диске.

В идеале страницы должны быть подлинкованы слева направо в порядке хранения данных. Вследствие расщепления страниц этот порядок может быть нарушен. Это приводит как к неполному заполнению страниц, так и к увеличению операций I/O вследствие непоследовательного положения цепочек страниц на диске – это вызывает дополнительные перемещения головок с цилиндра на цилиндр диска. А это одна из наиболее медленных дисковых операций.

Расшифруем результат:

Pages Scanned указывает количество страниц в таблице. В нашем примере их 20.

Extents Scanned показывает количество экстентов занимаемых таблицей. Это сразу указывает на фрагментированность данных – для сохранения 20 страниц хватает 3х экстентов.

Extent Switches говорит о количестве раз переключения с экстента на экстент при последовательном чтении данных. В идеальной ситуации это число равно Extents Scanned – 1

Avg. Pages per Extent говорит о среднем количестве страниц на экстент при перемещении по цепочке страниц. Это значение должно быть как можно ближе к 8

Scan Density представляет собой значение для внешней фрагментации. Этот результат получается от соотношения идеальной смены экстентов к фактической. Вполне очевидно, это что должно быть близко к 100%

Logical Scan Fragmentation дает процент страниц не в логическом порядке. Если страницы находятся в строгой последовательности слева направо, то данный параметр будет иметь значение 0

Extent Scan Fragmentation дает процент экстентов не в логическом порядке. Имеет то же логическое значение что и Logical Scan Fragmentation

Avg. Bytes Free per Page – должно быть как можно ближе к 0 если fill factor 100. Иное значение требует незначительных расчетов. Если fill factor 80, это обеспечивает примерно 1600 свободных байтов на страницу.


Avg. Page Density должно быть как можно ближе к 100%. Avg. Bytes Free per Page и Avg. Page Density дают хорошее представление о внутренней фрагментации.

В нашем примере мы имеем Avg. Page Density 98.19%, что означает что нет внутренней фрагментации (длина записей не всегда совпадает с размером страницы). С другой стороны Scan Density 60% и Extent Scan Fragmentation 40% говорит о внешней фрагментации. Если мы дефрагментируем таблицу а выполним эту команду еще раз, мы получим следующий результат:

.......................................

Ну и далее "по тексту" :-)

Удачи

(33)аа, просто ты "экстенты" употребил не к месту, тогда понятно.

(31)Спасибо.

Вот мне и интересно, если я просто в конфигураторе запущу реиндекс это достаточно будет?

(35) да.. "достаточно" :-)

(36)Спасибо  :)

(35)делать средствами самого сервера делать не просто нормально, а правильно.
И чем чаще делать, тем только лучше. Вставить переиндексацию, обновление статистики, шринкование, бекап в ночную процедуру обслуживания и не иметь больше хлопот.

Вопрос про размер БД, иммено про размер, был поставлен потому, что реиндексация БД при больших размерах занимает значительное время...

(39)большие - это сколько?
все относительно. Потому как озвученные 3 ГБ это ничто.

(38) "Вставить переиндексацию, обновление статистики, "

Мдя-я-я.. Отличний образчик ПОЛНОГО БРЕДА... Ну какое можт быть "обновление статистики" ПОСЛЕ реиндексации????

Короче... Оказывается не только про "экстенты" - "ни уха ни рыла".. так ещё и такую элементарщину не знаем :-))))

(17) ИМХО, статья написана тупым америкосом для тупых америкосов

(0) ИМХО, реиндексация из конфигуратора это аналог CREATE INDEX WITH DROP_EXISTING, так что то же самое можно делать с SQL сервера
а с SQL сервера делать удобней, т.к. можно настроить Job, см. (38)

(41)нука, покажи свои знания про индексы и статистику, а заодно про экстенты (что это), а я докажу, что ты ламер.

1. Буду подсказывать:
Экстенты - http://msdn2.microsoft.com/en-us/library/aa174529(SQL.80).aspx
ps: теперь после прочтения расскажи как ты будешь увеличивать размер экстента.

Спок.. Не-е-е.. ты лучше расскажи.. Блесни всей глубиной своего ЛАМЕРСТВА и раскрой своё "откровение" подробнее про "обновление статистики" ПОСЛЕ реиндексации...

А заодно расскажи про РАЗНИЦУ в результатах реиндексации сделанных "правильно аля спок" и реиндексацию через интерфейс 1С...

ё-ё-ё.. Давно так не ржал над такой ГЛУПОСТЬЮ :-))))

(45)имхо, ты дерево, возможно, даже дуб.
1. с экстентами понял, что сморозил глупость?
3. разницы в результатах между сделанных на самом сервере и через 1с нет.
2. сейчас дам про статистику почитать.

(46) Да чЁ с тобой про экстенты говорить??? Ты настолько ТУП что несёшь ПОСТОЯННУЮ чушь в элементарном...

ЗЫ... кури букварь.. только затем начинай щёки надувать :-))))

ЗЫЫ... Кстати "слив" про "обновление статистики" и про "реиндексацию" - защитан... Отмаза "дам почитать" - ну нИкатит ни разу :-)))

(47)т.е. вместо того, чтобы отвечать на вопрос переходишь на оскорбления? С твоей адекватностью не все впорядке.
Про статистику: ты же не поверишь на слово, нужно документальное подтверждение.

Про оскорбления - читай собственные постинги.. "как акнится - так и аукнится"...

фразы из твоих постингов:

spock (38) - 16.02.07 - 19:30

 - делать средствами самого сервера делать не просто нормально, а правильно.
 - И чем чаще делать, тем только лучше.
 - Вставить переиндексацию, обновление статистики

Это просто ШЕДЕВР ламерства... Они показывают что ты НЕ ЗНАЕШЬ даже элементарного и обсуждать с тобой что-либо "глубже" и серьёзнее - просто БЕСПОЛЕЗНО...

Ну а "упёртость в глупости" - только подтверждает "диагноз"...

Про статтистику:
Во-первых, у статистики задачи - определять селективность и распределение ключей в индексе.
В-вторых, статистика может быть без индекса (но индекс без статистики не может быть).
http://msdn2.microsoft.com/en-us/library/aa174544(SQL.80).aspx

(50) Млин... Продолжаешь ТОРМОЗИТЬ???

Давай по пунктам:

- делать средствами самого сервера делать не просто нормально, а правильно.

ПОЛНАЯ чушь... С точки зрения "результата" - абсолютно ПОФИК КАК (через что) "выдана" команда на реиндексацию... Что через "оснастку" ЕМ, что через кверианалайзер, что через 1С... Ну НЕТ тут "правильности"... Ну АБСОЛЮТНО пофик

- И чем чаще делать, тем только лучше.

ПОЛНАЯ чушь... в 99.99% всех баз сиквела под 1С у участников данного форума (а мы именно в этом контексте обсуждаем на данном форуме и в данной ветке сиквел) "излишняя "частота" только ВРЕДНА... делать реиндексацию "нормально индексированных" данных - бесполезно.. но вот та же   статистика ПОЛНОСТЬЮ "слетает".. так что тем самым мы например "усложняем" жизнь "предсказаниям"


- Вставить переиндексацию, обновление статистики

ПОЛНАЯ чушь...  Делать "обновление статистики" ПОСЛЕ переиндексации - это демонстрировать ПОЛНОЕ ламерство в вопросе.. "что такое статистика".. "откуда она берётся" и ЗАЧЕМ её нужно "обновлять"


Короче...Такая концентрация ЛАМЕРСТВА.. в КАЖДОМ предложении "длинного абзаца" - это безусловно нужно в мемориз... Ну а продолжающаяся "упёртость" с воплями "я ПРАВ" - это "диагноз".. :-)))

(51)я так понял ты читаешь только, что хочешь.
Под правильно подразумевается, что можно вставить в джоб и не делать этого руками - автоматизация понимаешь. Про результат переиндексации - см. (46).
Почему нужно делать переиндексацию - потому что индексы имеют свойство фрагментироваться, так же fillfactor отличный от по-умолчанию в процессе жизни индекса самостоятельно не поддерживается (изменяется заполненность). Переиндексацией "DBCC DBREINDEX" индексы пересоздаются по новой, что устраняет фрагментацию или же "DBCC INDEXDEFRAG" без пересоздания индексов. А чтобы после переиндексации статистика была адекватна (в отличие от тебя) нужно делать обновление статистики с fullscan.
Что такое статичтика я написал, и зачем она тоже.

епт, ты меня утомило, дерево.

http://users.v8.1c.ru/Adm347.aspx

Одно из ключевых условий эффективности использования Microsoft SQL Server состоит в создании такого набора индексов для таблиц, чтобы любые запросы к таблицам могли бы выполняться эффективно. С увеличением объема данных эффективность использования индексов может снижаться, приводя к увеличению времени выполнения операций по чтению и модификации данных. Microsoft SQL Server имеет свойство автоматического обновления статистики индексов, но для поддержания индексов в актуальном состоянии этого бывает недостаточно, поскольку Microsoft SQL Server не перестраивает индексы автоматически.

Проблема:
После выполнении интенсивных операций по модификации данных в таблицах базы данных увеличивается время выполнения запросов и операций по модификации данных.

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

Решение:
Регулярная переиндексация таблиц базы данных с помощью команды DBCC DBREINDEX ( table_name ).
Регулярная дефрагментация индексов базы данных  с помощью команды DBCC INDEXDEFRAG(database_name, table_name, index_name).
Выбор способа решения этой проблемы зависит от интенсивности операций по модификации таблиц базы данных.

Регулярная переиндексация таблиц базы данных является более эффективной процедурой, однако время выполнения у нее существенно больше. Кроме того, ее выполнение может замедлить работу пользователей, поскольку на время перестроения индекса блокируется доступ к таблице базы данных, индекс которой в данный момент перестраивается.

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

При высокой интенсивности операций модификации данных,  возможно использование комбинации этих методов:

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

Эту процедуру можно автоматизировать, написав скрипт на Transact-SQL, который будет исполнятся с требуемой периодичностью с помощью Microsoft SQL Server Agent.

Пример подобного скрипта оформленный в виде хранимой процедуры:

CREATE PROCEDURE DBReindex AS  SET NOCOUNT ON  DECLARE @TableName char(32)  DECLARE SysCur CURSOR FOR SELECT name FROM sysobjects WHERE type='U'  OPEN SysCur  FETCH NEXT FROM SysCur INTO @TableName  WHILE @@FETCH_STATUS=0 BEGIN      DBCC DBREINDEX(@TableName)      FETCH NEXT FROM SysCur INTO @TableName  END  CLOSE SysCur  DEALLOCATE SysCur
Аналогичный результат можно получит с помощью Database Maintenance Plan Wizard из SQL Server Enterprise Manager.

"Под правильно подразумевается, что можно вставить в джоб и не делать этого руками - автоматизация понимаешь. Про результат переиндексации - см. (46). "

гы-ы-ы.. "вертишься как уж на сковородке"??? Смысл???
Во-первых - где про джоб в твоём (38)
Во-вторых - а РАЗНИЦА между джобом в самом сиквеле, между джобом операционки и джобом в рамках 1с???

"Почему нужно делать переиндексацию - потому что индексы имеют свойство фрагментироваться"

А ну-ка.. а ну-ка... Раскажи... а с "какого перепуга" индексы "имеют свойство фрагментироваться" при "обычном режиме работы юзера 1С" и как сильно "фрагментруются индексы" при заведении например 100 документов.. ну-у-у
например счетов-фактур.. Что бы "орать не глядя", что И "чем чаще делать, тем только лучше" (что через каждые 5 минут "это делать" ЛУЧШЕ чем если "это делать каждый час")


" чтобы после переиндексации статистика была адекватна (в отличие от тебя) нужно делать обновление статистики с fullscan"

ё-ё-ё.. очередной ПЕРЛ ЛАМЕРА.. Ты это ещё в "Книгу знаний помести"...



Короче... продолжай юморить... Давно так не ржал над ламером :-))))

(54)бля, ты меня уже раздражаешь, дерево.
в (38) было сказано про джоб - "в ночную процедуру обслуживания". Это означет, что не человек сидит и руками запускает, а выполняется какое-то задание.
Про фрагментацию: ты хочешь меня убедить, что индексы не фрагментируются вообще или они фрагментируются в каком-то другом случае отличном от нормальной работы?
По мне так фрагментируются - тупо перепроводим документ (v77), это приводит к тому, что из RAxxx удаляются записи, принадлежащие документу, и вставляются новые + обновляются итоги на начало периода в таблице RGxxx.
Даже просто вставка документов приводит к пересчету RGxxx - это может приводит к фрагментации индексов.

ps: тебе бы не мешало подучить эту тему, могу посоветовать курсы от MS, только они дорогие.
ps: бля, ты прапором в стройбате чтоли служил?
ps: если не согласен с моими выкладками, то даказывай обратное. Мне надоело для тебя искать ссылки. Кстати, как с английским? Может нужно искать информацию на русском?

(55) "бля, ты меня уже раздражаешь, дерево. " (с) Спок

(48) - 17.02.07 - 08:49
т.е. вместо того, чтобы отвечать на вопрос переходишь на оскорбления? С твоей адекватностью не все впорядке.  (с) Спок

Это СУПЕР... Подобное (не только ОТКРОВЕННАЯ ТУПОСТЬ и ЛАМЕРСТВО) но и собстенный "диагноз" в собственном критинизме - это ПЯТЬ БАЛЛОВ.. Продолжай :-)))

" было сказано про джоб - "в ночную процедуру обслуживания". "

Т.е. джоб это синоним "в ночную процедуру обслуживания"???

!!!!  Очередной мемориз!!! валяюсь уже без сил под стулом :-))))


(сквозь слёзы хохота)... Ну хоть чуток "покури букварь" про статистику.. Откуда она берётся и чЁ можно "обновлять" если индексы созданы ЗАНОВО переиндексацией :-)))


Короче.. аФФтор.. пиши "ичО" :-))))

(пока еще снисходительно терпелив) На выпадки отвечать не буду, а то уподоблюсь деревянному стройбат-прапору.
"Откуда она берётся и чЁ можно "обновлять" если индексы созданы ЗАНОВО переиндексацией" - просто сил нет, как хочу знать твою версию. Просвети, а.

+57 епт, про увеличение экстента еще расскажи (чуть не забыл).

(57) тебя "просвещать" бестолку.. Ты даже элементарных азов не знаешь, но щёки надул уже выше кремлёвских башен..... Ну толку рассказывать про "Алгебру Ли" человеку, который таблицы умножения не знает??? :-)

(59)это ты так ловко уходишь от ответа? Молодец.

(60) от какого "ответа"??? Я показал что ты порешь ЧУШЬ.. показал с фактами и твоими же цитатами.. показал в каких именно местах и каких именно фразах.. показал конкретно всю глубину твоего ламерства... но ты этого до сих пор не понял.. и продолжаешь "вертется как уж".. "лепить горбатого" про джобы... Короче... Если даже после того как тебя "ткнули носом" ты продолжаешь по прежнему "дуть щёки2 - толку чЁ-либо тебе дальше объяснять? Это явная "клиника"...

(61)ни одно доказательства(!) твоих слов я не видел. А вот то, что ты несешь какую-то хню - видел.

+62 Давай так, ты отвечаешь на мои вопросы из 57+58 и если все правильно, то я посыпаю голову пеплом.

ждемс..

(62) прочитай внимательно (51).. Я там довольно подробно расжевал твой ламерство... Если с чем не согласен - аргументируй...

или ты поэтому и "тёмный" в сиквеле, что ещё и читать не умеешь???

(65)Хочу в виде Мой вопрос - Твой ответ, чтобы можно было корректно ссылаться на это.

(66) Повторяю... читай (51).. Там есть ПОЛНЫЕ цитаты твоего ламерства и ПОЛНЫЕ расжеванные на них комментарии...

(67)(уже вывел из себя)ебана, ты дурак или есть такой?

Вопрос 1: Что такое экстент? Как увеличить экстент?
Вопрос 2: Что такое статистика? Для чего нужна статистика? Почему ее не нужно обновлять(?) после переиндексации?

а большой брат смотрит...

(67)(уже вывел из себя)ебана, ты дурак или есть такой?  (с) Спок

(48) - 17.02.07 - 08:49
т.е. вместо того, чтобы отвечать на вопрос переходишь на оскорбления? С твоей адекватностью не все впорядке.  (с) Спок

Мдя-я... самодиагноз - "дуб" очевиден.. но зачем им так бравировать???

По остальным вопросам - с ламером чЁ общаться??? Ему нужно вначале азбуку подучить и букварь "по курить" :-)))

(70)все понятно, ты не знаешь ответов на эти вопросы.
Почитай ссылки, которые я привел выше - тебе нужно.

(71) Основная черта ламера - брякать вопросы в которых он сам ни уха ни рыла...

спок, лучше бы ты только вопросы задавал бы.. тогда за умного бы сканал.. А так.. когда начал раздавать "тупые советы" и прокололся.. показал всю глубину собственного ЛАМЕРСТА :-)

ЗЫ.. Ну бряки ещё чЁ нибудь... Рассмеши в очередной раз :-)))

ЗЫЫ.. "Для чего нужна статистика? Почему ее не нужно обновлять(?) после переиндексации?" (с) Спок - МЕМОРИЗ!!!! ПЯТЬ БАЛОВ!!! Ламерство у отдельных индивидумов - не истрибимо :-)))

(72) Мля.. ты опять за свое.
"Шура вы еще не отсидели за прошлое дело"

(72)Ты меня утомил. Отвечу на вопросы сам (хотя уже отвечал), так как ты не можешь и не знаешь.
1. Что такое экстент?
Логическая единица, выделенная под индекс, таблицу. Имеет размер в восемь страниц (страница - минимальная единица размером 8 КБ).
Как увеличить экстент? это к (26)
Ни как.

2. Что такое статистика? Для чего нужна статистика? Почему ее не нужно обновлять после переиндексации?
Информация, которая позоляет оптимизатору построить оптимальный план запроса. Определяет селективность данных и распределение (плотность) ключевых значений в индексе. Статистика может быть и у неиндексированных полей. Статистика имеет своиство устаревать, т.е. не соответствует действительности. Из-за этого sql-сервер может строить неоптимальные планы выполнения запросов.
Почему ее не нужно обновлять после переиндексации - это вопрос к прапорщику. Обновлять нужно (с ключем fullscan - будут прочитаны все строки для сбора статистики, т.е. статистика будет более точной).

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

(74) А кстати спасибо, даже базу занести можно было бы.
Если бы не маразм в (26)...(72)

(75)разозлил он меня.
Верткий же, на прямые вопросы не отвечает. Переводит все на опонента.

avmlvm, захочешь как-то аргументировать (74), то давай с сылками на bol. Я уже ссылки приводил выше.

(77) вроде не первый день на мисте)))...  сходи в поиск - ты не открыл америку))

(75) +1 "стучание ламера об стенку головой" - это естественный ламерский процесс... Он так же не поддаётся объяснению как и то, что при ПЕРЕСОЗДАНИИ индексов - "обновлять статистику" бестолку.. Т.к. у нас уже всё ПО НОВОМУ....
И НЕТ ниодного руководства по админству.. где бы была рекомендация по "обновлению статистики" при создании или перестроению ВСЕХ ИНДЕКСОВ...

(78) Кстати... Ты тоже оценил "перл" ламера что "И чем чаще делать реиндексацию, тем только лучше"???

Это нужно повесть в скрижали Мисты :-)

(79)При переиндексации физически происходит: drop index, create index. Соответственно, будет создана новая статистика. Но статистика будет полной (т.е. произойдет fullscan) только для таблиц размером до 8 МБ. Таблицы размером больше будут иметь не полную статистику плотности распределения ключевых ключей. Потому-то и следует делать обновление статистики с ключем fullscan. Некоторые могут этого не делать.

ps: все, дальше я пасс.

"При переиндексации физически происходит: drop index, create index. Соответственно, будет создана новая статистика"

ё-ё-ё.. Очередной перл ламера, который про "update statistics" слышал.. а вот про "сreate statistics" - ещё "не долистал" листочки... который не знает.. Что втоматическое И создание И обновление НЕ ОТМЕНЯЕТ (не заменяет) "ручное" создание и/или обновление

ламер безусловно НЕ ЗНАЕТ, что для "вновь созданной" статистики делать "обновление" статистика - БЕССМЫСЛЕННО...

Короче... ещё раз для ламера не умеющего читать и ну никак не осилившего (51)

Делать "часто" реиндексацию индексов, для и так "не фрагментированных" индексов не только "не полезно", но и ВРЕДНО.. Т.к. индексы и так "не улучшаются", а ты тратишь ресурсы на переиндексацию и ТЕРЯЕШЬ ранее собранную статистику...


"все, дальше я пасс." (с) Спок

Давно пора... Степень озвученной тобой глупости и так уже "зашкаливает"