ms offie
|
|
Noel | Дата: Среда, 22.01.2014, 11:06 | Сообщение # 16 |
Москва
Группа: Модераторы
Сообщений: 67
Репутация: 4
Статус: Offline
| У нас 1700.
|
|
| |
vad | Дата: Среда, 22.01.2014, 11:11 | Сообщение # 17 |
Барнаул
Группа: Проверенные
Сообщений: 223
Репутация: 17
Статус: Offline
| А на каком все это железе?
|
|
| |
logoff | Дата: Среда, 22.01.2014, 11:17 | Сообщение # 18 |
Тамбов
Группа: Администраторы
Сообщений: 655
Репутация: 19
Статус: Offline
| Ну тут больше от настроек приборов зависит.... Как много данных они передают... Ибо там идет работа по таблице истории - выборка из нее основная.
|
|
| |
vad | Дата: Среда, 22.01.2014, 11:22 | Сообщение # 19 |
Барнаул
Группа: Проверенные
Сообщений: 223
Репутация: 17
Статус: Offline
| переиндексировать и почистить. К примеру флит с 600ТС без топлива не справляется с обработкой поступающих данных на 4Г 2х2.5ГГц.
|
|
| |
logoff | Дата: Среда, 22.01.2014, 11:37 | Сообщение # 20 |
Тамбов
Группа: Администраторы
Сообщений: 655
Репутация: 19
Статус: Offline
| У меня точно меньше
Можно попробовать запускать процедуру для каждого маршрута отдельно. Если уж совсем плохо, можно заморочиться со скриптом/заданием, которое будет по одному маршруту запускаться, и собирать данные в единую таблицу, а потом останавливаться свою работу, и, например, высылать данные на почту.
|
|
| |
Noel | Дата: Четверг, 23.01.2014, 08:32 | Сообщение # 21 |
Москва
Группа: Модераторы
Сообщений: 67
Репутация: 4
Статус: Offline
| Цитата vad ( ) А на каком все это железе? Два ксеона 5660, 24 гб. оперативки и рейд из 4 ST3300657SS. Цитата vad ( ) переиндексировать и почистить Заморочусь с этим. Пробовал вчера реорганизовать PAPT_OrderControl, просто посмотреть, что получится. Если смотреть процент фрагментации по ПКМ > свойства, или в стандартном отчете sql, то 0 с копейками процентов. Если же этим скриптом, то после проведения реорганизации, процент чуть чуть упал, а количество страниц возрастало почти вдвое, общий процент фрагментации 25 %. Почему эти данные разнятся ? Может я сделал что-то не так ?
Цитата Можно попробовать запускать процедуру для каждого маршрута отдельно. Если уж совсем плохо, можно заморочиться со скриптом/заданием, которое будет по одному маршруту запускаться, и собирать данные в единую таблицу, а потом останавливаться свою работу, и, например, высылать данные на почту. Звучит заманчиво. А это сложно ?
Сообщение отредактировал Noel - Четверг, 23.01.2014, 08:37 |
|
| |
logoff | Дата: Четверг, 23.01.2014, 08:49 | Сообщение # 22 |
Тамбов
Группа: Администраторы
Сообщений: 655
Репутация: 19
Статус: Offline
| Цитата Noel ( ) Заморочусь с этим. Пробовал вчера реорганизовать PAPT_OrderControl, просто посмотреть, что получится. Если смотреть процент фрагментации по ПКМ > свойства, или в стандартном отчете sql, то 0 с копейками процентов. Если же этим скриптом, то после проведения реорганизации, процент чуть чуть упал, а количество страниц возрастало почти вдвое, общий процент фрагментации 25 %. Почему эти данные разнятся ? Может я сделал что-то не так ? Подсчет процента фрагментации - дело длительное. Когда вы это делаете через свойства - там данные точнее Когда через скрипт - то тот выводит данные "по ускоренной" методике (которая управляется параметрами в скрипте). Потому да, данные могут отличаться. ... Но правда не на 25%...
|
|
| |
logoff | Дата: Четверг, 23.01.2014, 08:52 | Сообщение # 23 |
Тамбов
Группа: Администраторы
Сообщений: 655
Репутация: 19
Статус: Offline
| Цитата Noel ( ) Звучит заманчиво. А это сложно ? Не, не очень сложно. - пара таблиц для хранения данных между сессиями, процедура их обработки "по одному маршруту"... Попробую заморочиться, как будет время. Интересная задача, ибо судя по всему у меня этот отчет никому не интересен, но его тоже не используют.
У вас настроена отправка почты средствами SQL database mail? http://technet.microsoft.com/ru-ru/library/ms186358.aspx
|
|
| |
Noel | Дата: Четверг, 23.01.2014, 10:31 | Сообщение # 24 |
Москва
Группа: Модераторы
Сообщений: 67
Репутация: 4
Статус: Offline
| logoff, неа, не настроено. Сейчас в свойствах не могу посмотреть процент фрагментации, чтобы сравнить, ошибки повалятся сразу. Но вчера вечером делал, точно разнились, в свойствах - 0 %, в скрипте - 25 или 21 %, не помню точно. А увлечение количества страниц должно быть?
|
|
| |
logoff | Дата: Четверг, 23.01.2014, 12:05 | Сообщение # 25 |
Тамбов
Группа: Администраторы
Сообщений: 655
Репутация: 19
Статус: Offline
| Тут видимо какой-то косяк со стороны движка в подсчете процентов и страниц... возможно... Не готов сказать - количество страниц должно быть одинаково, ибо оно и не считается, а просто хранится. Может в скрипте не правильно колонка называется...
|
|
| |
Noel | Дата: Четверг, 23.01.2014, 20:56 | Сообщение # 26 |
Москва
Группа: Модераторы
Сообщений: 67
Репутация: 4
Статус: Offline
| Цитата logoff ( ) Тут видимо какой-то косяк со стороны движка в подсчете процентов и страниц... возможно... Ох нет нет, это я "прогнал" В отчете "Физическая статистика индекса" тоже 21 % у индекса IX_PATP_OrderControl_ODD_SCHTIME. Видимо реорганизация ему не помогла.
Не знаю, что я там вчера реорганизовывал, глубокой ночью дело было, но сейчас все поучилось.Добавлено (23.01.2014, 20:56) --------------------------------------------- Правильно ли я понимаю, что перестроение нужно использовать только тогда, когда реорганизацией снизить процент фрагментирования не удается ?
Сообщение отредактировал Noel - Четверг, 23.01.2014, 19:23 |
|
| |
logoff | Дата: Воскресенье, 26.01.2014, 23:19 | Сообщение # 27 |
Тамбов
Группа: Администраторы
Сообщений: 655
Репутация: 19
Статус: Offline
| Не совсем. Это два физически разных процесса. Реорганизация больше всего похожа на дефрагментация, а перестроение - это повторная сборка индекса. При Реорганизации индекс доступен для работы, а при отмене задания все сделанные изменения останутся в БД. А при перестроении индекс не доступен (тут от версии SQL зависит, на более продвинутых индекс остается доступным), и при отмене запроса - индекс останется в первоначальном виде.
Перестроение быстрее обычно, чем полная реорганизация, после него уровень дефрагментации несколько обычно ниже (но его прерывать нельзя, и обычно пока оно делается ТОРМОЗА ДИКИЕ).
|
|
| |
Noel | Дата: Понедельник, 27.01.2014, 08:57 | Сообщение # 28 |
Москва
Группа: Модераторы
Сообщений: 67
Репутация: 4
Статус: Offline
| logoff, я руководствуясь вашей статьей настроил джобс и его прерывания. В 6 утра прервал, но сейчас не могу посмотреть данные о фрагментации, ни скриптом, ни отчетом. Цитата logoff ( ) Это два физически разных процесса. Хорошо. А что для нашей ситуации полезнее ? Или нельзя на этот вопрос ответить однозначно ?
|
|
| |
logoff | Дата: Понедельник, 27.01.2014, 11:15 | Сообщение # 29 |
Тамбов
Группа: Администраторы
Сообщений: 655
Репутация: 19
Статус: Offline
| Цитата Noel ( ) Хорошо. А что для нашей ситуации полезнее ? Или нельзя на этот вопрос ответить однозначно ? Полезнее, думаю пересчет полный. Вопрос только в том, что он может выполнять ОЧЕНЬ ДОЛГО. На своей системе я не рискую это делать. Ибо когда это делалось система встала больше чем на сутки с этим расчетом. Потому я через реорганизацию теми джобами.
|
|
| |
Noel | Дата: Понедельник, 27.01.2014, 14:54 | Сообщение # 30 |
Москва
Группа: Модераторы
Сообщений: 67
Репутация: 4
Статус: Offline
| Цитата logoff ( ) Полезнее, думаю пересчет полный. Вы имеете ввиду DBCC DBREINDEX или что то другое ? И еще вопрос, я так понимаю, что модель организации в БД в данном случае OLTP ? Под описание подходит.
|
|
| |