|
v7: 1С Комплексная, лавинообразно начали сыпаться ошибки. Помогите пролить свет. | ☑ | ||
---|---|---|---|---|
0
maxnn
10.04.12
✎
13:57
|
Имеем базу Комплексну - файловую. База доработана сильно. Размер базы 7 гигов. Самый большой ДБФ 1.3 Гига - это общий журнал.
60 Пользователей онлайн, 1000 документов в день в срднем. До прошлой недели всё просто летало идеально. Потом обновили релиз с 493 на последний, сохранив все доработки соответственно. После этого намного чаще начала появляться ошибка транзакции, что таблица занята пользователем и так далее. Но работала ещё сносно. К концу недели база вообще стопорнула. Полезли ошибки DATABASE ERROR 110, ругаясь на индексный файл. Тестирование и исправление, удаление индексных файлов и загрузка-востановление базы не помогло. При создании документа всегда выдавалась ошибка транзакции. Был обратно загружен старый релиз 493, правда план счетов остался новый, чтобы не пересчитывать итоги, так как делалось в рабочее время. После этого на несколько дней ошибка DATABASE ERROR 110 пропала, но работать в базе было не возможно из-за транзакций. из 100 документов создавалось несколько. В итоге щас из 60 человек в базе работает 2-3 чловека. заходит больше, снова лезут ошибки DATABASE ERROR 110 и ошибка транзакции. Помогает только выкидывание всех пользователей, переиндексация базы и запуск опять 2-3 пользователей. И это пока не зайдут ещё несколько. Из за чего такое могло возникнуть и есть ли какие пути решения кроме SQL? Интересует также, из за чего так внезапно всё накрылось. База работала идеально. P.S. Пока что решили чтобы быстрее вернуть базу - это перейти на SQL. Но из-за существенных затрат на это ищется также альтернативные пути решения. Вообще думалось, что до 2 гигового лимита база проработает 3 года. Уже идёт 3-тий год. В конце года планировалось просто свернуть базу и работать следующие 3 года без проблем. |
|||
154
opty
11.04.12
✎
01:31
|
Но скорость несколько упадет
В некоторых случаях чуть чуть , в некоторых случаях скажем так - заметно Возможно придется переписать некоторые отчеты (запросы) а может и нет |
|||
155
opty
11.04.12
✎
01:44
|
В общем если этот обор отключен программисту будет тяжелее строить отчеты непосредственно к проводкам , именно в разрезах номенклатуры , ибо отбора нет , всякие там ВыбратьПоЗначению() , но на самом деле это требуется достаточно редко . Бухзапросы просто замедлятся в некоторых случаях .
Например оборотка по 41 за месяц целиком будет строится с такой же скорость как и раньше , а вот напрмер оборотка скажем с 1-го по 15-е , может будет строится в два-три раза дольше , ибо там сам запрос выбирает проводки , а отбора-индекса то и нет Стандартный размен - объем на скорость :) |
|||
156
romix
11.04.12
✎
01:50
|
Чегой-то hogik-овые статьи на Инфостарте все удалены
http://www.peeep.us/41557f35 |
|||
157
maxnn
11.04.12
✎
01:51
|
(156) Он удалил все свои наработки с Инфостарта.
|
|||
158
opty
11.04.12
✎
01:53
|
16777215 вот оно волшебное количество записей в DBF при котором начинается кабздец
|
|||
159
opty
11.04.12
✎
01:55
|
При стандартном Kernel :)
|
|||
160
maxnn
11.04.12
✎
02:00
|
(158) оппа... У меня в 1saccsel 16 835 204 записи... Так занчит у меня из-за него база полетела?
|
|||
161
maxnn
11.04.12
✎
02:00
|
И какие последствия могут быть, если в таком режиме у меня несколько дней проработала база?
|
|||
162
opty
11.04.12
✎
02:04
|
(143) Если есть готовый инструментарий для свертки (стандартный желательно допиливать) то все упирается в объем базы и мощность железа . Сама свертка ну несколько часов идет если правильно все делать .
Месяц назад сворачивал свою скульную базу на миллион доков за 2011 , за все про все 9 часов , включая репликации , инструментарий естественно уже готов был . (160) Ога :( (161) Самые тяжелые :( |
|||
163
maxnn
11.04.12
✎
02:07
|
(162) А Kernel137 этот лимит поднимает до 2 млн всего лишь?
|
|||
164
maxnn
11.04.12
✎
02:07
|
(162) И как мне последствия такой работы проверить? Просто перепровести доки за последнюю неделю и всё встанет нормально?
|
|||
165
zak555
11.04.12
✎
02:09
|
(164) см. (145)
ты будешь не движения формировать, а итог сразу за месяц по всем документам за период |
|||
166
romix
11.04.12
✎
02:09
|
(158) FFFFFF в шестнадцатеричной системе однако
(0) 60 пользователей это много для ДБФ, выгружайте в SQL, если не выгружается то есть опять же патч (я пейсал). Книга знаний: Плагин для лечения выгрузки и загрузки больших баз в 1С 7.7 |
|||
167
opty
11.04.12
✎
02:14
|
(163)Плюс минус , несколько поможет , но ...
(164) Не факт , могли доки вообще потеряться , хотя у тебя врят ли , проблем с 1SCRDOC нету , не записались проводки , или док удален а проводка осталась (свободная проводка) Все таки КАЧЕСТВЕННЫЙ переход на скуль , особенно большой и сильно переписанной базы , дело не одного дня , если по уму , и активно используемая бухия однако то же вопросы вызывает. Срочная свертка , или срочное отключение отбора , даст время на размышления |
|||
168
maxnn
11.04.12
✎
02:17
|
(167) Только что отключил отбор... После реорганизации количество записей в 1saccsel не изменилось. Размер остался тот же. Все изменения делались в течение 15 минут. При сохранении файл 1saccsel был создан заново.
|
|||
169
maxnn
11.04.12
✎
02:18
|
(167) Есть какие мысли?
|
|||
170
maxnn
11.04.12
✎
02:19
|
(166) А модифицированная kernel37 до какой планки поднимает тогда это число?
|
|||
171
opty
11.04.12
✎
02:23
|
Так , конфигуратор-проводка посмотри какие отборы стоят
Может стоять только разрешить отбор , а может еще по дебет-кредиту и для всех |
|||
172
romix
11.04.12
✎
02:25
|
(167) Да какие там вопросы. У нас всю жизнь была SQL везде. Гораздо кошернее и стабильнее.
(170) 2 гига на файл у них физический предел (лимит для целого числа со знаком). |
|||
173
opty
11.04.12
✎
02:26
|
Если стоит только галка "Разрешить отбор" тогда плохо , её лучше не отключать
|
|||
174
opty
11.04.12
✎
02:27
|
(172) Стабильней - абсолютно точно , масштабируемей , и плюшковатей
|
|||
175
romix
11.04.12
✎
02:28
|
(174) Экспертам НАСА виднее :-))
|
|||
176
opty
11.04.12
✎
02:30
|
(175) НАСА уже перешли на 1С в связке со скулем :))
|
|||
177
maxnn
11.04.12
✎
02:33
|
(171) У меня стоит галки в "Разрешить отбор" и "Для всех".
Какие дальше действия Кэп? |
|||
178
romix
11.04.12
✎
02:34
|
(176) Да они даже на метрическую систему перешли с дюймовой. http://science.compulenta.ru/301905/ С проста ли.
|
|||
179
zak555
11.04.12
✎
02:35
|
(178) РФ пустит штаты на луну ?
|
|||
180
opty
11.04.12
✎
02:37
|
Ну можно снять все галки вообще :)
Тогда у тебя этот файл просто исчезнет , некоторые отчеты в которых задействован отбор счетов будут считаться медленно , очень медленно Ними калку Для всех , и попробуй установить количество уровней 1 , файл должен уменьшится заметно |
|||
181
opty
11.04.12
✎
02:38
|
Сними галку для всех , в смысле :)
|
|||
182
maxnn
11.04.12
✎
02:39
|
(180) Снял... Идёт сохранения...
А на что это отразиться? |
|||
183
maxnn
11.04.12
✎
02:42
|
Я вот что заметил. Копаю щас файл 1SACCSEL сегодняшний в DBF Viewer 2000.
В этом файле первое поле ab Accid, так вот напротив этого ab стоит везде зелёная галка, а в конце файла на нескольких сотен записей вместо зелёной галки стоит красный крест. О чём это может говорить? |
|||
184
maxnn
11.04.12
✎
02:43
|
Повторюсь, количество записей 16 835 204.
В копии базы до того как появились проблемы кол-во записей 16 592 499 |
|||
185
opty
11.04.12
✎
02:47
|
(182) Перестанут работать отборы по счетам , точнее по субсчетам в журнале проводок , это ерунда
Перестанет работать програмный отбор по журналу проводок по субсчетам , используется редко , то же ерунда А вот то что выполнение бухзапросов к субсчетам замедлится и довольно сильно , не очень хорошо , оснобенно не за цельный месяц . Если отбор отключит вообще то в разы |
|||
186
opty
11.04.12
✎
02:49
|
(183) Это может говорить о том что давно не делалась упаковка таблиц базы
|
|||
187
maxnn
11.04.12
✎
02:51
|
(185) Сохранились изменения. 1SACCSEL стал вместо 730 Мб 236 Мб. Количество записей с 16 млн уменьшилось до 6 млн.
|
|||
188
opty
11.04.12
✎
02:56
|
(187) Сбоить по блокировке не будет :)
Теперь надо будет уточнить у программиста , работает ли он напрямую с журналом проводок , есть ли специфические отчеты , и не использует ли он в них отборры по счетам , если нет то просто следить за общим падением быстродействия бух отчетов и документов использующих запросы к бух данным . Если в целом падение быстродействия не критичное , так и оставить :) |
|||
189
opty
11.04.12
✎
03:00
|
Не плохо было бы сделать бэкап базы (скопировав всю базу) , а потом сделать выгрузку загрузку , базы , ну или как минимум тестирование-исправление с упаковкой таблиц ,после того как в рабочей базе будет отключен отбор для всех , и оставлен отбор по первому уровню счетов .
|
|||
190
maxnn
11.04.12
✎
03:07
|
(189) А по сути, для чего мы это делали если у меня стоит уже модифицированный kernel37? Он же это ограничение снимает?
Как я понял 16777215 это и есть проблема 2-ух млн строк? |
|||
191
opty
11.04.12
✎
03:17
|
(190) Недокументированный метод :)
kernel37 в основном снимает ограничение на размер файла в 1 гбт . Несколько по другому строит индексы в DBF , вылетов и блокировок скорее всего не будет , но по поводу корректного построения отчетов на таком количестве записей могут возникнуть проблемы . Больше 16777215 не надо , никаких гарантий корректности |
|||
192
maxnn
11.04.12
✎
09:01
|
(191) Не помог kernel37, всё равно полезли ошибки когда все в базу вошли.... Щас удаляю отбор у номенклатуры и в проводках на рабочей базе...
|
|||
193
opty
11.04.12
✎
09:18
|
(192) После удаления отборов , все равно сделай тестирование-исправление , и обязательно проверить код на использование программных отборов .
Если количество движений по субсчетам счетов распределено не равномерно , сильного замедления бухзапросов не будет бли отключении отбора по счетам "Для всех" и ограничении одним уровнем . А по уму так надо базу смотреть , так трудно сказать |
|||
194
Ёпрст
11.04.12
✎
10:28
|
(91) Сыми галку отбор по счетам и этой таблички не будет вовсе, твои бухи один хрен его не используют.
|
|||
195
Ёпрст
11.04.12
✎
10:29
|
именно из-за этого файла у тебя все ошибки сейчас.
|
|||
196
Ёпрст
11.04.12
✎
10:29
|
(192) не надо этого делать.
|
|||
197
Ёпрст
11.04.12
✎
10:29
|
+ нужен именно kernel33, а не 37
|
|||
198
opty
11.04.12
✎
10:44
|
(194) Используют , но не явно :)
Полностью снимать отбор со счетов не рекомендуется , а вот ограничить первым уровнем вполне компромисный вариант |
|||
199
Ёпрст
11.04.12
✎
10:46
|
(198) ерунда это всё..
Для комплексной, всё можно. +можно в разы уменьшить файло проводок. |
|||
200
opty
11.04.12
✎
10:46
|
200 :)
|
|||
201
opty
11.04.12
✎
10:48
|
По уму , для комплексной вообще можно проводки за месяц формировать по итогам опер учета , но у ТС , бухгалтера так не хотят , в результате бухия очень сильно раздувается
|
|||
202
opty
11.04.12
✎
10:49
|
+(201) И нужно вообще то :)
|
|||
203
Ёпрст
11.04.12
✎
10:49
|
(201) там всё делается гораздо проще.
|
|||
204
maxnn
11.04.12
✎
12:07
|
(193) После Снятии "отбора" и "для всех" база заработала нормально.
(197) А разве kernel37 это не тот же kernel33 только ещё с исправление загрузки процессора при ожидании? (202) Буду прорабатывать этот вариант. |
|||
205
Ёпрст
11.04.12
✎
12:09
|
(204) нет
|
|||
206
maxnn
11.04.12
✎
12:11
|
(205) В текстовом файле идущем с библиотеками вот что было сказано
"В комплекте имеется файл Kernel37.dll. Эта библиотека решает (кроме проблемы 1 гигабайта) еще и проблему “100% загрузка процессора при ожидании блокировки”." |
|||
207
Ёпрст
11.04.12
✎
12:14
|
(206) всё вопросы к автору
http://infostart.ru/profile/304810/ 37 - раньше была для других решений, типа адвантадже |
|||
208
FN
11.04.12
✎
12:48
|
(158) откуда инфа? есть авторитетные ссылки?
а то я проексперементировал - забил справочник 16977214 элементами и "кабздец" не наблюдаю вот про >1 гБ - с этим сам сталкивался, а про (158) - не в курсах... |
|||
209
Ёпрст
11.04.12
✎
12:51
|
(208)
Ошибка возникает при непосредственном удалении записи (в терминах 1С) в таблице с количеством записей более 16777215 штук. Ошибка возникает при непосредственном удалении записи (в терминах 1С) в таблице с количеством записей более 16777215 штук. Удаляемые записи могут располагаться и до этой границы. Сообщение об ошибке указывает на индекс "IDELETED" с индексным выражением "D" и выражением фильтра "DELETED()". Этот индекс используется для нахождение помеченных на удаление записей (в терминах DBF) и размещения на их месте новых добавляемых записей в таблицу. Первые кандидаты на такой количество записей: 1SCRDOC, 1SACCSEL. Способов устранения проблемы, пока, не найдено. Мнение разработчиков по поводу этой ошибки: http://www.codebase.com/support/kb/?article=C01054 Допускаю, что такое проявление ошибки было привнесено именно в 1С. Т.к. продукт "CodeBase" продаётся с исходными текстами и "встраивался" в 1С с некоторыми изменениями на уровне исходных текстов разработчиками 1С. Само ядро "CodeBase" находится в библиотеке DBEng32.dll. Эта библиотека одинаковая для версий 1С: 18, 25, 27. Другие версии не проверялись. Временное решение проблемы в ручном режиме. Суть способа: Отключить индекс "IDELETED" для проблемных таблиц. Естественно, отключится механизм использования помеченных на удаление записей (в терминах DBF). А это приведет к более быстрому росту размера таблицы. Частично решает проблему установка "Kernel3x", т.е. снимается ограничение на размер DBF файла в 1 гигабайт. Но при использовании данной разработки категорически нельзя использовать прямые запросы на FoxPro. Кроме этого придется чаще (регулярно) выполнять упаковку таблиц и внимательно отслеживать рост размера таблиц, т.к. существует ограничение на размер DBF файла в 2 гигабайта. Последовательность действий: 1) При возникновении ошибки -310, на любой рабочей станции, срочно выгнать всех пользователей из 1C. Не сохранять никаких открытых форм ввода информации. Прекратить (прервать) выполнение отчетов. И т.д. Если произошёл сбой при выполнении регламентных работ, то восстановить базу с последней копии. При этом заранее оповестить всех пользователей об возможности появления такой ошибки и довести до них информацию о действиях в таком случае. 2) Т.к. в сообщении об ошибке -310 не выдаётся имя таблицы, то необходимо найти эту таблицу силой ума или тупым открытием подряд всех DBF-ов в порядке от большего размера файла к меньшему. Ищем таблицы в которых количество записей подбирается или уже больше 16777215 штук. 3) Удалить все CDX файлы. Зайти в сессию 1С монопольно и выполнить, тем самым, реиндексацию. 4) Вызвать утилиту обслуживания DBF/CDX структур. Например, бесплатную утилиту "Advantage Data Architect" можно скачать по ссылке: http://devzone.advantagedatabase.com/dz/content.aspx?Key=20&Release=13&Product=8&Platform=6 5) Открыть проблемную таблицу в формате "FoxPro (DBF/CDX)". Вызвать свойства таблицы. Выбрать закладку с описанием индексов. Найти индекс "IDELETED". Изменить выражение фильтра с "DELETED()" на ".F.". Сохранить изменения с реиндексацией. Закрыть таблицу. 6) Открыть таблицу "1SUSERS" (DBF файл без индексов). В поле "USRSCNT" установить значение больше нуля. Закрыть таблицу. Выйти из утилиты. 7) Запустить сессию 1С в монопольном режиме. Согласиться с реиндексацией. Дополнительная информация: 1) Необходимо повторять действия по отключению индекса после каждого удаления файлов CDX. После реиндексации без удаления файлов повторять отключение индекса не надо. 2) Данная технология проверялась только на тестовой базе. В промышленной эксплуатации - нет возможности проверить, т.к. у нас не возникала ошибка -310 при использовании "родного движка" и мы уже давно перешли на другу СУБД. 3) Надеюсь найдутся заинтересованные люди, и напишут утилиту для автоматического анализа проблемных таблиц и не ручного отключения ©hogik |
|||
210
Он
11.04.12
✎
12:51
|
Ромикс уже считал. В файле может быть 2 млрд.записей (_StrToId("ZZZZZZ"
)) |
|||
211
FN
11.04.12
✎
13:05
|
(209) ага... вот где собака порылась.
Значит если непосредственно удаление запрещено, то в принципе работать со справочниками/документам можно. Главное что бы системные таблички (итоги, движения регистров и тп) не пухли |
|||
212
Ёпрст
11.04.12
✎
13:12
|
(211) читай внимательнее, дело не в "непосредственном удаленинии объектов"
|
|||
213
FN
11.04.12
✎
13:17
|
(212) дык вроде внимательно прочитал. Вот на примере справочника - в идеальных условиях "удаленных" записей у нас быть не может. Естественно к движениям регистров, итогам, 1scrdoc и тп это не относится - там движок сам "удаляет"...
|
|||
214
Ёпрст
11.04.12
✎
13:18
|
(213) так и есть.. думал ты про 1SCRDOC речь ведешь
|
|||
215
Ёпрст
11.04.12
✎
13:19
|
я ужо неоднократно упирался в это ограничение.. на 1SCRDOC
|
|||
216
FN
11.04.12
✎
13:25
|
(215) у меня _1SACCSEL давно за 20 перевалил и RA1051 уже 15
а вот _1SCRDOC всего 7 но конфа не типовая, так что видимо взаимосвязей между доками меньше чем в типовых. Спасибо за разъяснения. |
|||
217
Ёпрст
11.04.12
✎
13:33
|
(216) сыми отбор по счетам и.. 1SACCSEL исчезнет
:) |
|||
218
opty
11.04.12
✎
13:50
|
(217) Ага , а потом тащись как удав по шкурке №5 от скорости исполнения такой конструкции
Ит.ВыполнитьЗапрос(Дата1, Дата2, Счет, КорСчет, Валюта, 3, ВидПериода) особенно когда Дата1 и Дата2 не равны началу и концу месяца А если Счет и КорСчет списки то вообще Совсем отбор по счетам убирать нельзя , в теории и с DBF можно вообще без индекса работать , но как то не очень |
|||
219
Ёпрст
11.04.12
✎
13:56
|
(218) фигня это всё, в комплексной всё можно, если грамотно порезать аналитику в проводках, которая дублируется регистрами
|
|||
220
opty
11.04.12
✎
14:05
|
(219) Разговор не идет о том что МОЖНО в комплексной , разговор идет о выплнении запросов к бухгалтерским данным , и о влиянии на это отборов .
Можно вообще все на регистрах сделать , в теории , "умельцы" вон складской учет на одних справочниках пишут . У ТС бухгалтерская часть в комплексной "живая" , о чем и писал выше , и да это не самый оптимальный вариант , но уж так повелось , и вопрос в том что ему надо было сейчас что бы заработало , чем когда нибудь правильно . Если он сейчас полностью отключит отборы по счетам , база может встать колом , не известно что и как там дописано по бухкомпоненнте . Даже отключение "По всем" оставляло такую теоретическую возможность (правда очень незначительную) |
|||
221
Ёпрст
11.04.12
✎
14:07
|
(220) база не встанет колом, это раз.
Комплексную оптимизировать надо изначально, это два. |
|||
222
opty
11.04.12
✎
14:10
|
(321) Комплексную оптимизировать надо изначально - 100 % согласен
Если полностью отключить отборы по счетам , при "живом" проведении по счетам в реальном време (с расчетами остатков и средневзвешенной) встанет |
|||
223
opty
11.04.12
✎
14:11
|
Или по крайней мере имеет значительную вероятность
|
|||
224
Ёпрст
11.04.12
✎
14:20
|
(222) не встанет, проверенно на 20 гиговой базе в дбф
|
|||
225
opty
11.04.12
✎
14:22
|
(224) Круть , а че до 30 гиг на DBF не довели ?
|
|||
226
Ёпрст
11.04.12
✎
14:25
|
(225) предел в 2 гига на файло достигли, пришлось резать
|
|||
227
maxnn
11.04.12
✎
14:32
|
(226) А можно узнать причину того, почему на SQL не переходили?
|
|||
228
Ёпрст
11.04.12
✎
14:49
|
(227) зачем ?
|
|||
229
Ёпрст
11.04.12
✎
14:50
|
платить за скуль и его лицензии как-то не улыбает
переписывать все модули проведения, чтоб доки "ездили" быстро - тоже. |
|||
230
opty
11.04.12
✎
14:50
|
Относительно небольшая (средняя) бух база - чуть больше 4 гиг
1SACCSEL около 9 миллионов записей Стандартная синтетеческая оборотка по субсчетам с включенным отбором по счетам за период 15 окт - 15 дек строится 2.5 сек , если отключить отбор полностью ,7.5 секунд . С одной стороны мелочь 5 сек , с другой стороны в три раза дольше . Если задействовать счета исключительно для регламентной отчетности , раз в месяц по цельному месяцу или кварталу , с расчетом проводок по данным опер учета (как в принципе и надо) да еще если анадатику упростить , до достаточно-необходимой фигня . И в таком случае отбор можно полностью отключить Если же постоянно , при проведении каждого документа расчитывать данные (остаки например по счетам) , да еще и по полной аналитике , далеко не фигня . У ТС как раз второй случай . (228) Интересно сколько идет реиндексация или тестирование исправление такой базы , кроме шуток интересно |
|||
231
Ёпрст
11.04.12
✎
14:51
|
а если тупо в скуль закинуть - на наших объемах всё колом встанет, проверенно.
|
|||
232
Ёпрст
11.04.12
✎
14:52
|
(230) на одном серваке 30-40 минут, на другом 15-20, это реиндекс.
ТиИ не делается по причине отсутствия в его необходимости |
|||
233
opty
11.04.12
✎
14:53
|
(231) Об этом тоже писал выше , нормальный переход на скуль, дело не быстрое , и к ней надо готовится , тем более не известно что там подонаписано
|
|||
234
maxnn
11.04.12
✎
14:55
|
(229) Эх.. мне бы твою уверенность и твои познания... А то я говорю что дешевле и для нас лучше 100-150 тыс потратить на полную оптимизацию нашей ДБФ базы, чем 500 тыс тратить на скуль, да ещё и новый гемор приобрести....
Программист говорит что нужно переходить на SQL, так как все большие конторы работают на SQL и что с ДБФ при таких объёмах уже никто не работает... И руководство соглашается с его доводами. |
|||
235
Ёпрст
11.04.12
✎
14:57
|
(234) да какие проблемы ?
Пусть развернёт тебе скуль (хотя бы не лецинзионный), закинешь туда базу, заведешь юзверей на денек - посмотришь на реакцию и всё свалишь на программиста:) пусть переписывает и оптимизирует |
|||
236
Ёпрст
11.04.12
✎
14:59
|
(234) >>>> все большие конторы работают на SQL и что с ДБФ при таких объёмах уже никто не работает
ну это враньё, работают и еще как. |
|||
237
maxnn
11.04.12
✎
15:01
|
(236) Ну и как мне это обосновать?
|
|||
238
Ёпрст
11.04.12
✎
15:02
|
(237) да никак, всё познается в сравнении.
Закинуть базу в скуль большого ума не надо. А вот заставить её работать со скоростью, хотя бы сопоставимой с дбф - вот в этом и будет затык. |
|||
239
Ёпрст
11.04.12
✎
15:04
|
+238 под "скоростью" я понимая время проведения документов, а не получение отчетов с ИБ.
Которые и в дбф варианте мгноввенно извлекаются при должном умении |
|||
240
opty
11.04.12
✎
15:06
|
(232) Извиняй , но не очень то верится , 4-х гиг база , на очень не хилом железе индексится около5-6 мин , скорость индексации растет не линейно .
А ну у тебя как то и 10-гиг база за 10 мин реиндексировалась :) Преимущество скуля никак не в скорости :) |
|||
241
opty
11.04.12
✎
15:10
|
(237) Почитай форум , преимущества скуля и DBF обсуждались многократно .
Я например то же считаю что темк еще можно и нужно оставаться на DBF , хотя сам сторонник SQL . Вот будет за 50 активных пользователей , потребуется работа 24/7 , потребуется интеграция с например OLAP серверами , тогда скуль без вопросов . |
|||
242
FN
11.04.12
✎
15:12
|
(240) ты у него лучше про дисковую подсистему спроси
например на ССД реиндексация ускоряется в несколько (до 10) раз по сравнению с зеркальным САТА-рейдом |
|||
243
Ёпрст
11.04.12
✎
15:13
|
(241) ну у нас 60-70 активных юзверей, работа круглосуточно, за исключением воскресенья (хотя и в воскресенье теперь в ночну смену выходят)
и ничего, живём как то. |
|||
244
Ыщъ
11.04.12
✎
15:16
|
Опять таки прямозапросечника в штат надо брать. А он ОстаТыщ запросит.
|
|||
245
AquaMan
11.04.12
✎
15:19
|
Вряд ли у вас скуль будет работать с приемлемой скоростью, доработки скорее всего писались на объектной модели, сервер столько запросов не потянет) Переходите на восьмерку)
|
|||
246
Ёпрст
11.04.12
✎
15:21
|
да -да..переходите на снеговика - там тормозов в разы больше.
+ нет никакого контроля в конфе..просто праздник какой то! |
|||
247
viktor_vv
11.04.12
✎
15:23
|
Я как-то легкомысленно закинул одну ДБФ базу в скуль. Там еще и конфа какая-то левая и старая была. Больше одного дня не выдержали. При беглом анализе оказалось, что там переписывать дохрена и еще чуть-чуть.
|
|||
248
G-Re
11.04.12
✎
15:23
|
(234) Пригласи "программиста" в эту ветку, пусть аргументированно объяснит свою позицию не руководству, а простым специалистам.
|
|||
249
Ыщъ
11.04.12
✎
15:24
|
(247) Вот поэтому "спецов", безапелляционно заявляющих: "Только Скуль", пинком под зад.
|
|||
250
FN
11.04.12
✎
15:32
|
(243) ты про винты все же расскажи - что там на сервере стоит?
|
|||
251
Ёпрст
11.04.12
✎
15:35
|
(250) да ничего особенного .. немножко винтов в 10-ке.. хотя лучще всё же 0 ставить.
|
|||
252
Torquader
11.04.12
✎
15:56
|
А в прошлые года и периоды очень часто заглядывают ?
А то есть мнение, что прошлые данные можно хранить в другой базе, в которую, при необходимости, заглядывать из основной. |
|||
253
opty
11.04.12
✎
16:11
|
(252) Свертку уже предлагали , но по каким то не очень понятным причинам , такой вариант не очень канает
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |