1 Сколько одновременно работающих пользователей ?
2 какой релиз 1с сколько документов за день есть ли какие отличия от стандартной 1с
3 какая sql2005 (sp ???) . Есть ли 3gb  wae ?
4 Как можно подробней опишите железо сервера  и какая ос, что еще крутиться на  sql сервере Также опишите структуру сети и какие протоколы используете.

noxxx писал(а) 30. Октября 2009 :: 10:52:


А вот этого не советую.
Стандартное Исправление добъёт окончательно твою базу.

Z1 писал(а) 30. Октября 2009 :: 11:37:


1. В данный момент 48 пользователей

2. Платформа 27, в среднем в день 1500-2000 документов, от стандартной 1С (ПУБ) осталось мало. Т.е. написано и дописано много всего. 1С++ используется только для селектов, никаких записей в базу не делается.

3. SELECT @@verinfo: Microsoft SQL Server 2005 - 9.00.3077.00 (Intel X86)   Dec 17 2008 15:19:45   Copyright (c) 1988-2005 Microsoft Corporation  Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2). Не знаю что такое 3gb wae 

4.
Сервер:

CPU: 2 x Intel XEON 5110
Мать: Supermicro X7DVA
Память: 6GB FBDIMM DDR2
Диски: Рейд контроллер Adaptec SCSI RAID 2020ZCR, 4 винта, raid 5
ОС: Windows 2003 Server R2 + все критические обновления и обновления безопасности

На SQL сервере больше ничего не крутится, кроме самого SQL. Иногда там запускают 1С для проведения закрытия месяца. Больше ничего.

Структура сети - между серверами и компами ИТ-отдела гигабит, далее идет сотка до свитчей, в которые воткнуты клиенты. Всё находится в одной подсети. Используем всё стандартное (TCP/IP, UDP, мониторинг оборудования по SNMP).

Одолевают блокировки, юзеры часто жалуются. Помониторили SQL-сервер - загрузка проца в среднем держится на 30-40%, памяти используется 2.7 Гб.

---

В ПКО есть ПриЗаписиПерепроводить(1);
Отладчиком пока не смотрел.

по пункту 4 где стоит ОС на отдельном диске или на RAID ?
Какие диски в  массиве интерфейс и скорость вращения ну и тип ?

Т.е правильно я понимаю у Вас 4 физич диска сконфигурированы
в 1 логич диск с архитектурой RAID 5 ?

Гипертрейдинг включен выключен ?
Сколько процессоров показывает диспетчер менеджер ?

Сервер собирали сами или бренд ? Какая мощность блока питания ?

Z1 писал(а) 30. Октября 2009 :: 13:25:


1. 4 физических диска сконфигурированы в 2 логических с архитектурой RAID 5
2. Гипертрединг включен, диспетчер показывает 4 процессора.
3. Сервер DEPO, мощность БП сейчас сказать затруднительно, т.к. физического доступа к серверу не имеем.

Цитата:

процессор Intel XEON 5110  двухядерный.
и показывает 4 ЦП значит гипертрейдинг выключен.

Z1 писал(а) 30. Октября 2009 :: 13:40:


Блин, 4 диска в одном массиве. На массиве два логических раздела. Я это имел ввиду.

Eprst писал(а) 30. Октября 2009 :: 13:58:


При мне ничего такого не делали. Человек, который был до меня любил править таблички вручную. Это он считал высшим пилотажем. Так что кто его знает что там делали ...

Главный вопрос что теперь с этим со всем делать

Eprst писал(а) 30. Октября 2009 :: 14:03:


Ну не факт что эту таблицу он правил. Я знаю только про таблицы регистров, и с ними мы уже справились.

То что исправлять - это понятно. Как исправлять что б ничего не поломать? Очень жду подсказок от местных Гуру 

Z1 писал(а) 30. Октября 2009 :: 14:06:


Менять raid5 на raid10?
Физических диска точно 4. Точно SCSI. Мощность БП пока сложно сказать. Что можно поковырять что б выяснить причину бития документов?

noxxx писал(а) 30. Октября 2009 :: 13:57:


т.е на сервере один логич диск из четырех физич. дисков
объедененных в RAID 5 ?
И на этом логическом диске и Операц система и база данных ?
Правильно ли я понял ?

noxxx писал(а) 30. Октября 2009 :: 14:01:

Давайте сначала с сервером разберемся.
Класный у Вас человек был. А если он еще и
с конкретным менеджером "дружил" ...

Z1 писал(а) 30. Октября 2009 :: 14:22:


А подойдет ли для журнала транзакций отдельный винт SATA?

В посте (0) ВЫ сказали что у Вас есть одна переф база.
В той переф базе dbf или sql.
Как настроена миграция документов , справочников ?

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

Z1 писал(а) 30. Октября 2009 :: 14:45:


По всем регистрам всё ок, проверка _1suidctl в файле. Ошибок меньше.

Z1 писал(а) 30. Октября 2009 :: 14:57:


Железками можно будет заняться на праздники только. До этого момента что-нибудь еще можно проверить?

Почему УРБД. Ведь если обмен идет каждые 20 минут
значит у Вас есть канал связи
и может рассмотреть возможность работы в терминале без УРБД ?

По БП: Мощность 750 W
По винтам: 4 x 73.5 Gb U320SCSI Fujitsu <MAW3073NP> LVD 68pin 10000rpm 8Mb

Поехал домой, через час появлюсь.

Далее конролерр с памятью
а как у него настроено кеширование с обратной записью ?
Даже если и правильно настроено то вполне может сбоить
да и батарейки в нем нет а кеш есть что будет с данными при очень кратком отключении питания на самом контролере ?

Ну и уж чтобы окончательно убедиться что
представляет из себя твой сервер прогони тесты

solio  http://www.sql.ru/subscribe/2005/273.shtml#20

SQLIOSim http://www.sql.ru/subscribe/2007/361.shtml

SQLIOStress http://support.microsoft.com/kb/234656/ru

Сам никогда не делал этого

Если будешь прогонять тесты то напиши здесь статейку(manual)
чтобы другим было легче воспользоваться.

Сделал (по крайней мере попробовал сделать) тест SQLIO. Нашел очень хорошее объяснение всего этого дела по адресу http://msmvps.com/blogs/gladchenko/archive/2009/06/09/1694801.aspx
Сделал 2 теста по 4 в каждом - случайное и последовательное чтение/запись в двух размерах блоков. Размеры выбирал по табличке из той же статьи. 8 Кб, как наиболее часто используемый для данных системы OLTP и 64 Кб, как данные журнала транзакций.
Результаты во вложенном файле. Т.к. дел с серверами не имею, то и мало представляю себе какая скорость должна быть и как можно оценить ту что получилась у меня 
Жду ответа многоуважаемого Z1

Z1 писал(а) 02. Ноября 2009 :: 08:02:


Охохо ... Я вчера пробовал погонять SQLSim (прочитал, что оно сделано вместо SQLStress), в начале теста получил ошибку:

CreateFileStream Error: 0x80070032
Error Text:
Description: Unable to get disk cache info for D:\
 

Потом тест прошел без ошибок:

Closing file D:\sqliosim.mdx
File Attributes: Compression = No, Encryption = No, Sparse = No
Target IO Duration (ms) = 100, Running Average IO Duration (ms) = 15, Number of times IO throttled = 2974, IO request blocks = 16 Reads = 3087, Scatter Reads = 14670, Writes = 286, Gather Writes = 21813, Total IO Time (ms) = 19822101
DRIVE LEVEL: Sector size = 512, Cylinders = 26769, Media type = 0, Sectors per track = 12, Tracks per Cylinders = 63
DRIVE LEVEL: Read cache enabled = No, Write cache enabled = No
DRIVE LEVEL: Read count = 17757, Read time = 646055, Write count = 23568, Write time = 19226797, Idle time = 9017, Bytes read = 5840797696, Bytes written = 5579250688, Split IO Count = 0, Storage number = 2, Storage manager name = FTDISK
Closing file D:\sqliosim.ldx
File Attributes: Compression = No, Encryption = No, Sparse = No
Target IO Duration (ms) = 100, Running Average IO Duration (ms) = 116, Number of times IO throttled = 118, IO request blocks = 1
Reads = 0, Scatter Reads = 0, Writes = 1415, Gather Writes = 0, Total IO Time (ms) = 141449
DRIVE LEVEL: Sector size = 512, Cylinders = 26769, Media type = 0, Sectors per track = 12, Tracks per Cylinders = 63
DRIVE LEVEL: Read cache enabled = No, Write cache enabled = No
DRIVE LEVEL: Read count = 17757, Read time = 646055, Write count = 23578, Write time = 19226799, Idle time = 9022, Bytes read = 5840797696, Bytes written = 5579291648, Split IO Count = 0, Storage number = 2, Storage manager name = FTDISK
Buffer Pool: validated buffers 309170, pages 377585, discarded buffers 363156 

Но осмыслить и интерпретировать результаты пока не могу. Буду читать.

Цитата:

Выровняйте сразу кластера - не пожалеете.

По опыту ознакомления с материалами SQL.ru предпочтительней 64К.

noxxx писал(а) 02. Ноября 2009 :: 08:28:



Размер логич блока надо ставить 64 Кб ( если Вы знаете почему надо ставить больше то совет про 64 Вам не нужен)

Речь идет об  этом - ошибке в Win200, win2003
http://www.gilev.ru/1c/hardware/RAID.html это актуально
для всего диска ( raid ) поэтому заголовок статьи пропускаем, а статью читаем.

PS
В win2008 это исправили и ничего делать в win2008 не нужно.
там размер нулевого блока равен  1МБ.

noxxx писал(а) 03. Ноября 2009 :: 06:32:

Перед установкой сервера Вы должны точно знать всю конфигурацию файловой системы т.е. иметь рисунок физического и логического
разбиения дисков и где будут работать основные элементы :
ОС, БД, журнал транзакций.

noxxx писал(а) 03. Ноября 2009 :: 08:15:

это зависит от recovery model. Как ее выбирать либо слишком простой либо слишком сложный вопрос.

В своих базах использую simple.

Опять же ведь у Вас урбд так и делайте обмен раз в час вот Вам и будет точно копия базы на час назад.

Ну также никто не мешает вам на журнал транзакций тоже ставить raid-1 Просто рекомендация по разбиению файловой системы была дана в предположении что Вы не будете менять диски.
Если это не так то и рекомендация неверна и возникает очень много вариантов.

noxxx писал(а) 03. Ноября 2009 :: 09:00:

ms sql сначала пишет данные в журнал транзакций потом в файлы данных.
При моделе simple в журнал транзакций пишется более сокращенный набор изменений ( по сравнению с full ) - за счет этого simple быстрее. Может еще быстрее и за счет того что при simple журнал сам усекается но не уверен влияет ли это на скорость или нет.

Расшифруйте что Вы понимаете под падением сервера - тогда
можно сказать какая модель лучше хуже. нет идеальных решений на все случаи.
( а то может у Вас сервер с пятого этажа упадет    )

noxxx писал(а) 03. Ноября 2009 :: 09:15:

Если физич. диск останется рабочим то возможны два варианта
1. Хрень будет вне файла ну тогда вроде некритично если весь
диск не полетит потому что nfts вроде как сама журналируется
и имеет защиту от повреждений.
2.Хрень коснется Вашего файла тогда  : sql на страницах хранит контрольные суммы. Наверное он их как-то обрабатывает.
Т.е. из плохой страницы точно ничего не восстановить без танцев с бубном, а для модели simple может эта страница отсечется и операц. система больше не будет писать в плохую область диска.

Ну а чтобы уменьшить вероятность проблем с диском или его частью и были придуманы RAID массивы.

На x86 он больше, чем 2.7 использовать и не будет. Разве что AWE включить, но оно только для кэша будет использоваться.

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

Попробую прогнать sqlsim.

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

noxxx писал(а) 05. Ноября 2009 :: 10:17:

1.Исправлять базу от того что кто-то изменял значения руками.
2.Заменить переф базу код 'iv ' на какой либо трехзначный (анг буквы)

Dimitry писал(а) 05. Ноября 2009 :: 11:50:

Не секрет потому что 1с для sql версии использует явные  и неявные преобразования между типами
varchar(9) char(9)
и это может может привести к ошибке( в ранних релизах точно приводило) или наткнуться из-за этого еще никем не найденные
ошибку ? зачем когда гораздо легче избежать ее( солому подложить)

Вы сами в своих прямых запросах тоже можете ошибиться и после этого такую ошибку будет ой как нелегко обнаружить.

PS грубый пример

ТЗ = СоздатьОбъект("ТаблицаЗначений");
ТЗ.НоваяКолонка("СтрДок","Строка");
Запрос = СоздатьОбъект("ODBCRecordSet");
ТекстЗапроса = "
|SELECT top 10
|  Жур.IDDoc
|FROM
|  _1SJourn Жур (nolock)
|";
Запрос.ВыполнитьИнструкцию(ТекстЗапроса,ТЗ,0);
 

Строки в ТЗ могут получиться как 8 символьные ( если iddoc содержит последний пробел)  так и 9 символьные.

noxxx писал(а) 05. Ноября 2009 :: 12:27:

Можно. Меняешь коды когда никто в обеих базах не работает.
Стоит менять или нет решай сам.

noxxx писал(а) 05. Ноября 2009 :: 14:38:

Все старые исправить а новых ошибок не должно возникать.
разбираться почему появляются.
У всех не появляются у Вас появляется.
Вы что хотите сказать что sql сервер сам придумывает какие-то движения (и даже записывает их по нескольким таблицам) ?

noxxx писал(а) 06. Ноября 2009 :: 09:39:

Может документ пришел из переф базы и там были созданы именно такие движения.
Сделай документ непроведенным. Снова проведи.
Появились или нет "левые" движения ?

Ветку не хочется всю перечитывать.
У тебя вроде базы одинаковые я имею ввиду параметры миграции
e документов справочников регистров констант какие ?

Z1 писал(а) 06. Ноября 2009 :: 10:10:


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

Мое мнение.
1. На выходных сделай полный обмен.

2. делаешь копии всего и sql и каталогов баз ( центральная + переф базы).

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

Ну сам посуди.
Что у тебя сейчас с базой непонятно.Там из-за некоректных действий что-то нарушено. Найти все что там нарушено либо нереально либо надо очень много времени.
В твоем случае легче из переф базы все перевостановить.
Ну также перед выполнением этой операции можешь проверить какие либо показатели.
Остатки на складах.Взаиморасчеты по важным клиентам.и.т.д.
Опять же у тебя останутся копии и можешь их развернуть на вспомагательном сервере(псевдосервере)

Также можешь потренироваться и сначала все предложенное сделать.как бы на копии и убедиться что все работает.

Ну и конечно такие координальные действия нужно делать через руководство чтобы оно знало что ты исправляешь "недоделки"
предшественников.

Тем более сам говоришь база стала лучше работать т.е. у тебя уже есть положительные результаты  

Что-то вы не туда пошли - сервера, УРБД, бекапы....

Для начало нужно определится что за глюк -  "железный" или "софтовый". Судя по топику глюк выражается в том, что в определенном файле (или группе файлов) мы имеем записи, которые там быть не должны. Когда происходят проблемы при записи на диск, связанные с железом, то обычно вместо необходимых записей мы получаем "мусор" - набор символов, не несущий информации. В нашем же случае мы имеем структурированную информацию, которая полностью отвечает всем необходимым параметрам. Тоесть с точки зрения железа - все правильно, никаких нарушений. Неправильность видится со стороны софта - согласно бизнес-логики программы - в регистре этих "правильных" данных быть не должно. В результате этого коротко анализа можно с большой долей вероятности забыть про сервера/винты/память и прочее.
Давай-те лучше рассмотрим подробнее софт:
На мисте (ссылка из первого поста) Ёпрст давал ссылку на описание таблиц 1С - вот с их изучения и надо было начать - там видно логику работы 1С с таблицами БД - как взаимосвязаны регистры и документы и тп.
Теперь попробую описать действия 1С при проведении и отмене проведения документа (рассмотрю только регистры).
При проведении документа 1С добавляет в регистры записи, которые в качестве указателя на документ имеют поле IDDOC (такой же как у нашего документа в 1SJourn). Логично предположить, что если мы вручную в регистр добавим запись с любым движением и IDDOC равным нашему документу, то в режиме 1С у этого документа добавится еще одно движение. Но при перепроведении документа эта запись удалится. Объясняется это тем, что 1С (в случае установленной галки автоматическое удаление движений) при начале проводки выбирает все движения документа в регистрах и "чикает" их, а потом записывает новые движения.
Теперь объясню как "происходит" глюк у автора:
Во-первых: глюк произошел только один раз - в момент "одновременной" проводки проблемных документов. Проверяется легко: снимаешь с проводки свой ПКО, а затем выбираешь движения этого документа с помощью такого кода
Рег=СоздатьОбъект("РегистрПоКоторомуВисятЛевыеДвижения");
Рег.ВыбратьДвиженияДокумента("НашПКО");
Пока Рег.ПолучитьДвижение()=1 Цикл
Сообщить("есть движения по регистру!");
КонецЦикла;
То-есть "мусор" в регистре уже лежит, причем давно - проводка и удаление документа ничего не меняет.
Объясняется все это очень просто:
в журнале документов 1SJourn, есть специальные поля на каждый из регистров - при проведении в них ставится флаг, что документ имеет движения по определенному регистру. Сделано это затем (ИМХО), что бы при удалении движений документа (снятие с проводки) не сканировать все регистры на предмет наличия движений,  а только те, в которые писали при проведении.
Так вот в твоем случае документ ПКО имеет движения по регистру, который не отмечен в 1SJourn - соответственно при удалении дока эти движения и не удаляются.
Последствия лечить довольно легко:
1) удалить лишние движения (я давал пример кода на мисте)
2) поставить нужную галку в 1SJourn и перепровести документ (сам не пробовал, но в теории сработает)
3) ТИИ - долго, но надежно (не надо кричать, что ТИИ побьет базу - в подавляющем большинстве базу бьют "сверхумные" админы)

Причина глюка:
Точно не скажу причину (не хватает мне опыта для подобных исследований), но умные люди подсказали несколько очень правдоподных вариантов forum.mista.ru/topic.php?id=391827



Сорри за длинный текст.

ЗЫ если я оказался в чем-то не прав - обязательно поправьте.

Автор пишет появляются левые движения ( заметьте не итоги  а движения )

Цитата:

При отмене проведения все движения документа из таблицы ra удаляются. удаляются командой sql delete .
Если эти движения остаются в ra это говорит о диком нарушении индексации в sql. Такого я еще ни разу не встечал. ( в dbf
были проблемы с индексами).
При отмене проведения флаги rf... - сбрасываются 1с программой.

Когда есть несоответсвие полей rf c движениями ra (речь о конкретном документе)  то в УРБД при обмене 1с падает по duplicate key . У автора этого не происходит.


Базу "правили" руками. Что там могли сделать и сколько нужно времени чтобы  это исправить.
Откуда известно что только регистры изменили ?

Смотри есть две базы которые должны быть идентичны а этого нет.
В одной есть ошибки в другой нет.
Мое мнение легче заново создать(пересоздать) УРБД чeм искать баги в базе после ручного редактирования.

Цитата:
не нашел ни одного варианта решения в этой ветке одни только предположения. Может назовешь конструктивное предложение из этой ветки ?

Речь о тестовой базе
у тебя ошибка в написании кнопки
     Рег.ВыбратьДвиженияДокумента(ТекущийДокумент);
надо передавать
Док.ТекущийЭлемент() где Док = СоздатьОбъект("Документ");


Если написать на форме журнала еще одну конпку

Процедура Движения1()
	Рег=СоздатьОбъект("Регистр.Новый1");
	Рег.ВыбратьДвижения();
	Пока Рег.ПолучитьДвижение()=1 Цикл
		Сообщить("Есть движение по регистру Новый1");
	КонецЦикла;
	Рег=СоздатьОбъект("Регистр.Новый11");
	Рег.ВыбратьДвижения();
	Пока Рег.ПолучитьДвижение()=1 Цикл
		Сообщить("Есть движение по регистру Новый11");
	КонецЦикла;
КонецПроцедуры 

То результат равен ( после пометки на удаление)
Цитата:



это также подтверждается что посмотрел в ra15.dbf нет записей
в ra18.dbf есть одна запись.
Смотрел Excel т.к. на компе даже нет уже вьювера dbf.