Ситуация следующая:
есть ИБ (ПУБ с доработками, на SQL2005), пару недель назад начал глючить отчет "Карточка счета", ТИИ выдало кучу ошибок. Анализ ЖР показал, что определенные ошибки тянутся еще с прошлого года.
Взяли последний бакап ИБ, развернули на локальной машине, переиндексировали и сжали базу средствами скуля, потом провели ТИИ - все прошло гладко. На вопрос "чозанах?", админ, а обслуживает серванты сторонне подразделение, начал строить из себя мегагуру, который не желает общаться с презренными смертными, выкинув странную фразу, мол ваша проблема решается за 30 минут, вы не обращались, я и ничего не делал: "МНОГОЛЕТНЫЙ и НЕ ТОЛЬКО МОЙ опыт общения с 1С показывает что попытки СВАЛИТь все на базовую инфраструктуру (SQL, citrix) заканчиваются ничем. Есть конкретные рекомендации от 1С. Есть понимание принципов её работы. Предлагаю руководствоваться этими постулатами и не придумывать велосипед без колес (журналы транзакций, логи и т.д.)". Т.е. пиняйте на свою 1С, а меня не трогайте.

По сему вопрос:

Верны ли для 1С v 7 SQL следующие утверждения

1) простая очистка журнала транзакций перед проведением тестирования однозначно позволит устранить некоторые регулярно проявляющиеся ошибки!

2) реиндексации в SQL 7.0 и 2000 базы 1С регулярно проводимая такая операция дает ощутимые результаты (наверное в производительности) ?

Книга знаний: Автоматическое сохранение (backup) базы 1С:Предприятие средствами SQL

1. нет, если модель базы simple.
2. ещё большей производительности даёт регулярная выгрузка/загрузка. Переиндексация тоже даёт, но не ощутимые. Ащутимыми они будут только если долго (полгода) не выполнялись.

ЗЫ. Админа выгнать на* без выходного пособия, поскольку обеспечение мониторинга и работоспособности входит в его обязанности, а не в обязанности бухгалтеров

Получается, что выгрузка-загрузка имхо решила проблему, следовательно, выполнение Shrink и переиндексация на SQL тоже могли решить проблему в рабочей ИБ?

А админу лениво проводить профилактику средствами SQL... что-то здесь не так, или я не чего-то недопонимаю.

Если "админу лениво проводить профилактику" - то увольнять по служебному несоответствию.

(5) у него другой босс. Вот скажи - в (4) верно думаю или нет?

(6) Если помоголо, то проверь ещё раз. Еслир всё нормально, тогда поможет.
А если у админа другой босс, то официальный документ его начальнику с требованием возмещения ущерба :-)

(2) Имхо п. 2 бред, где у 1С написано что нужно регулярно нужно делать выгрузку-загрузку ??? Переиндексировал и всего делов.

(0)
1) нет
2) нет

(8) А подумать над структурой данных? Помогает, поверь.

(10) Может быть както поменяется структура МД-шника, при загрузке, но данные в СКЛ от этого не поменяются. Единственно данные выстроятся в соответствии с кластерными индексами, что достигается как раз переиндексацией.
Базе 6 лет ниразу выгрузку-загрузку не делали, никто не плачет. Раз в год базу обрезаем проводим ТИИ

(9) поясни

(11) а) уберётся мусор из таблиц итогов регистров. б) уберётся мусор из _1sconst в) переорганизуются записи в таблицах.
Всё это увеличит производительность на нетривиальной базе.

В СКЛ никакого мусора нет, так что можешь не волноваться, стандартных средств поддержки СКЛ базы достаточно. В ДБФ - да физически остаются движения после распроведения документа, но они удаляются если сделать сжатие базы.

(14) Правда?? А нули в итогах куда делись? Грузины радами разнесли? Ты бы посмотрел для начала...

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

(0)
1. Нет. Когда меняешь МД у тебя и так чистится. Устраниться может только после реиндексации.
2. Нет. Смотря насколько часто меняете данные (структуру). Как по мне - 1 раз в месяц более чем достаточно. Ну и конечно от объема базы зависит, хотя для скуля - несущественно. Так что ни о каком глобальном увеличении производительности речи и быть неможет.
------------------
Для того что б избежать подобного - правильно делайте бекапы и по ночам реиндексируйте базу. Думаю поможет. И присутствие админа там ненужно - настраивается 1 раз и в шедулер.
Но если вы "зажимаете" бабло - ничто вам непоможет.
Как вариант, если неустраивает этот админ, поробуйте поработать с другим админом или прогом 1С который знает всю эту "кашу". Потом сделаете выводы.

>данные выстроятся в соответствии с кластерными индексами
кластерный индекс и есть данные. поэтому они и так уже выстроенны.

(17) так и что надо сделать на скуле, что будет равносильно выгрузить-загрузить из 1С? просто периодическую реиндексацию?

(18) Про фрагментацию индекса слышал когданибудь ???

(19) Нужно заплатить админу и все будет пучком.
Нужны ответы - читайте мануалы по скулю и об особенностях хранения данных 1С в скуле. Там все есть, но это займет время. А так - платите админу нормально и недергайтесь по мелочам. Удачи вам.

(20) Судя по тому что автор спокойно выгружает-загружает данные 1С-кой, то объем базы "детский". И недумаю что у автора стоит несколько серверов с настроенным распределением нагрузки. Поэтому о какой-либо фрагментации нестоит и говорить.
Скорей всего встал извечный вопрос: и хочется что б все пучком было, но и платить особо нехочется. Вот на автора щас и взваливают еще и админство.

(21) складывается впечатление, что вопрос оплаты для тебя весьма болезненный. Могу заверить, что этот админ не бедствует, получая свое ежемесячное жалование, которое раза в 2 минимум выше среднегородского уровня.

Работа администора как раз и заключается обеспечение надежности.
профилактика является наиболее эфективным и наименее затратным способом.
Разделение обязанностей по обеспечению надежности - задача руководителя ит службы . если мерориятия не регламентированы - всегда будет перевод ответственности между смежными подразделениями.

данный конфликт есть повод для пересмотра организации работы ИТ службы.

(23) Да. Я люблю работать и зарабатывать. И мне это нравится.
Ну если нормально платите тогда попробуй из (17):
"Как вариант, если неустраивает этот админ, поробуйте поработать с другим админом или прогом 1С который знает всю эту "кашу". Потом сделаете выводы."
ХЗ. Может действительно ваш админ "зажрался". Хотя че-то сомневаюсь... В любом случае "попытка - не пытка".

(24)
>Работа администора как раз и заключается обеспечение надежности.
>профилактика является наиболее эфективным и наименее затратным способом.

Согласен полностью

>Разделение обязанностей по обеспечению надежности - задача руководителя ит службы . если мерориятия не регламентированы - всегда будет перевод ответственности между смежными подразделениями. данный конфликт есть повод для пересмотра организации работы ИТ службы.

"Разруха в головах" (с) М.А.Булгаков
Два юрлица в рамках одного холдинга. Одно крутит сервантами, другое кодит в 1С и продают друг-другу услуги.

(25) Хотелось бы попробовать "свежую кровь", но как сказано выше - там свое начальство и мы к нему не имеем никакого отношения.