Уже стало привычкой перед окончательной публикацией показывать свои литературные опусы читателям мисты и инфорстарта. Коллеги, прочтите и покритикуйте? Что пропустил замыленным глазом, а в чем допустил ошибку.
--
http://legion-service.org/sposobi_optimisasii_1c77dbf.html
--
Спасибо заранее.

респектабельная для админов база. при более 100 еще и 75 пользователей держать..
это чистый 1С, или приблуды от тойскл и тд и тп??

поправил чуток статью. разбил её на разделы 1)Советы по предварительной настройка программного окружения 2) Советы по оптимизации конфигурации 1С 7.7 DBF
---
1 раздел дописал парой пунктов. думаю там более дополнять нечем.
2 раздел дополню завтра или в пятницу

(391)  в пятницу ненадо..

(392) надо Федя надо! )

(392) еще же четверда вроде, не? :)

(390) оперативная база - всего 50.
прямые запросы - в основном отчеты, олап-кубы, всякие фишки типа Контроль выполнения заказов на уровне производства (148)(149)

(394) дак в пятницу я сам буду развлекаться)) а пока время сурьезных дел. Критику учитываю потихоньку и правлю статью

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

а чо стало то?? в чем проблемс?? миста все решит))

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

"Впрочем, последний релиз платформы 7.7 действительно выпущен в далеком 1999 году." - да латна, 7.70.027 вышла 18.12.2006... пестабол...

ЧЕТЫРЕЗЗЗЗЗЗТА

(399) такого человека называют ламер, ламерюга, ламо

(400) ламер - это когда не понимает, но хотя бы не скрывает, что он ничего не знает... а тут - более запущенный случай, когда не понимает, но изо всех сил пыжится, что суперспец...

Чайник - не понимает и не лезет
Ламер - не понимает, но лезет

(0) жесть, учебник русского языка срочно в руки

(401) когда "не знает - но понимает, что не знает" - это вполне нормальный человек. Возможно, просто "чайник". Пока "чайник". Но "плох тот чайник, который не мечтает стать самоваром"©
а вот когда не знает, но делает вид, что знает - это уже ламеризм.

(401),(404) сублимируйте мои друзья не стесняйтесь))) вечером почитаю ваши излияния)

Mikeware вы что то подрастеряли задор, не? Кричим ламер сильнее дружнее !!))) А ведь вы сами ламер....я это не хотел озвучивать на публике, но не удержусь чувствую...

Симптоматично то, что Mikeware, как он сам признался в каком то из постов - почти не оптимизировал файловые базы DBF. Смешно не правда ли?))))) На критику он горазд))) Тем более знает же теоретически какие способы оптимизации бывают. А вот какие из них действенны - ни в зуб ногой) Но критиковать мы любим

>>>> Правило №2:
1. Учитывая реалии современной жизни, а именно тот факт, что жизнь современной операционной системы без антивирусной программы немыслима – проводим тонкую настройку антивируса. Никогда не используйте в настройках исключений антивируса – исключение всего каталога с информационной базой 1С. Нужно задать исключения только для файлов с масками: $lk, *.cfg, *.mlg, *.ert, *.efd, *.log, *.upd, *.md, *.dbf, *.cdx, *.xml. Все остальные файлы в каталоге базы 1С антивирус должен сканировать. Тем самым вы "убьете двух зайцев": избежите “торможения” базы 1С из-за антивируса, и не позволите вирусам спокойно плодится в укромных подкаталогах каталога информационной базы 1С.

Автор ЛаМЕР!!!  :)
Ты еще забыл поставить в исключение базы SQL

(407) ... На критику он горазд))) ....  Но критиковать мы любим
тогда в чем смысл: "v7: Покритикуйте пжлста - "Взгляд в прошлое, или Способы оптимизации больших баз 7.7 "
может стоило: "Покритикуйте чутка, не жестко ... " или "Скажите мне, что в общем все клево, но ..."

(408) речь об оптимизации ДБФ-ных баз, при чем тут скуль? О_О

(410) А у Вас молоко убежало (опять сервер упал)

(410)В топку DBF, писать, дак все сразу :)

>>>> Еще одно узкое место платформы 1С 7.7 – это константы. Методологически разработчиками 1С для констант отводилась роль хранения часто используемой, но редко изменяющейся информации (поэтому, наверное, разработчики 1С сочли возможным объединение всех констант в одну таблицу). На практике же, программистами часто допускается ситуация, когда в константы часто пишется некая информация. Такая методика приводит к печальным последствиям.

Жаль, что не пятница "поэтому, наверное, разработчики 1С сочли возможным объединение всех констант в одну таблицу", не знаю чем они там думали, но не головой, разве что только головкой :)

+(412) Там же, ниже автор приводит много фраз "Блокировка", но текст не дает понятия, что делать или не делать. Полная лажа. :)

+ Никогда не было мысли, в константу писать все время ;)
...Автор еще забыл сказать про периодические реквизиты...

(411) не, серваки - в норме, енто домен заартачился, от и маюсь от безделься ... Боссы колдуют че-то с ним)

(413) бывает и нужно, когда счетчик сторонний организовать нужно - проще, чем справочник-пустышку юзать

вообще-то некоторые советы описаные в статье дадул улучшение только для локальной базы, а если она в виде сетевой шары то они приведут к УЖАСУ...

почему автор не хочет признать, что установка 1с DBF может выполнятся совсем по разному и работать в разных окружениях? например старенький новель с шарой 1с сильно обгонит мелкомякгую шару...

ихмо автор пишет статью исходя из личного опыта ОДНОГО КОНКРЕТНОГО СЛУЧАЯ !!!

>>> Правило №2:
1. Используйте константы по назначению. Недопустима, например, такая ситуация, когда при проведении каждого документа в некую константу записывается информация.

"Доктор, а я буду жить?" :)
Пункт бред

(415) Классический пример - МОД организовал счетчик создаваемых объектов в константе и создал очередь к 1sconst.
Нужно и проще - не значит, что нужно именно так.

(407) Да, с мелкими базами я практически не работал. Да, я знаю теорию, и мне не надо подбирать способы оптимизации методом тыка. а тем более - не надо тупо копипастить чужие методики. Собственно, и тут, на форуме, советов по оптимизации я давал людям гораздо больше, нежели вы. так что..

>>> Примечание: для платформы 1C 7.7 SQL существует более эффективный инструмент – “гибкие блокировки”, но в данной статье платформа 1C 7.7 SQL рассматриваться не будет.

Ой, нашёл про SQL и магические фразы "Гибкие блокировки", но что за этим стоит, автору невдомёк :)

(417) житьь-то будешь. Только ты попрофилируй обращение к константам... ужаснешься.

(413)(420) у меня сложилось ощущение, что он не понимает, зачем нужна блокировка журнала при проведении...

>>>> 1. Т.к. вы работаете с информационной базой DBF, приближающейся к предельному объему, не искушайте судьбу – записывайте документы не более 1 документа в секунду.

Все, я в ступаре, автор, подскажи, как пользователю записать за секунду больше одного документа. При том, что он его еще должен заполнить :)

...пояснять, надо, что речь об обработки группы документов, но порой проще без пауз записать 100 документов, нежели с паузами, епаться, пару суток :)

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

(422) да вообще снять все блокировки, изменить уровень изоляции и будет все летать!

вот это я понимаю ОПТИМИЗАЦИЯ !!!

:)

>>> Рекомендую иногда проверять размеры файлов 1sjourn.dbf и 1sjourn.cdx (журнал документов). В норме размер индексного файла должен быть примерно в 1,5 раза больше размера файла dbf. Если у вас соотношение размеров этих файлов кардинально другое (например индексный файл меньше файла dbf - чего быть никак не может) – то это один из признаков неисправности журнала документов.

Как правило, если это произошло, то странно что еще не выросли регистры или журнал проводок, а тем более журнал расчетов :)

Сколько не видел БД, так у них журнал документов не превышал 1 Гб :)

(423) это происходит, когда один вид дока проводится быстро с разных терминалов
например у нас ожидание блокировки таблицы - обычное явление, хотя база на скуле 2005 крутится

(426) приезжай дарагой - пакажу)

>>> ГЛАВНАЯ ПРОБЛЕМА БОЛЬШИХ БАЗ 1С 7.7 DBF:

Главная проблема больших БД, это неправильное решение поставленной и постановка задачи :)

Если БД, разрастается, а отрезать нельзя, а в статье пользователь не сказал об свертки БД, которую по правилам необходимо делать.

+ Итого:

Решение автора статьи разделить на два пункта, автору не помогло, тормоза так и остались :)

(425) Ну что ты мне-то рассказываешь? :-) я это и так знаю. И ты знаешь. И ты знаешь, что я знаю. И Я знаю, что ты знаешь. :-))))
вопрос в том - знает ли это пейсатель...

(427) Зря ты ввязываешься в полемику. То, что тебе в наследство досталась относительно большая база, не значит, что ты можешь львов за хвост дергать.
Судя по вопросам в твоей ветке - как кодер ты еще в начале пути.

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

(432) "в споре рождается истина") а читал бы ветку внимательно - на начало пути не поставил бы
хотя согласен - я нуб - и енто клево)))

(433)Сверт DBF БД - это регламентная операция :)
Проводится раз в год, как правило...

Если у вас объем накопленной информации переполняется раньше, чем за год, то надо думать и смотреть в сторону другого программного обеспечения.

(433) + Вертай... причем тут вообще, свертка БД, это не полное удаление, а чистое архивирование, т.е. Сворачиваемая БД остается доступна пользователям.

Если ты свернул, и удалил копии прошлых продаж, то это твои проблемы :)

(433) срок исковой давности - 3 года. за это же время все взаиморасчеты болжны быть либо произедены, либо списаны за счет резервов. да и товар, пролежавший 10 лет - проще и дешевле принять не по той цене, по которой отпускали, а по бросовой. Либо вообще списать в убыток.

(433)+ в справочнике уже более 5,000,000 элементов

А 5 000 000 элементов, это не предел ;)
Так то их намного больше ID поле содержит 36-тиричный формат числа, состоит из 6-ти символов.

И того максимум элементов 2 176 782 336

(435, 436) не проканает - это теоретически клево - на практике засекали - частое обращение к данным 5-10 давности.
на счет другого ПО - хотелось бы Оракле, да зуб не ймет

(439)Это все проблема разработчика Конфы, как написал, так и тормозит :)

(438) конечно не предел - я тесты гонял на 120,000,000 перед внедрением - пришлось графы из справочников создавать - чтобы увеличить скорость доступа - запросы тупо садились в ж...

(441)А это уже проблема того кто выбирает программное обеспечение.
Так то 1С 7.7 для малого бизнеса :)

+ Семечками торговать, в ларьке...

+ В Акцесе это дело не быстрее будет работать :)

+ К тому же, автор хотел трезвый взгляд, на его статью, то он её получил. :)
Статья отстой и мало, что может, ему еще писать и писать :)

(442) Наивный) Дали 1С 7.7 сказали нужно сделать - а как - не ипает - лишь бы работало
в принципе это тестовая наработка - никто не знал что понадобиться - скоро на 8.2 все перетянем

(445) рано ему еще писать. мозгов-то нет. Разве что статьи умных людей перерабатывать...

(445) не судяй жестока - чел обидиться) для локальных ДБФ-ок покатит, особенно для начинающих)

(446) волшебное слово "восьмееееерка" :-)))
зы. "такой большой, а сказки веришь"©

(447) известное правило

если ты сам не умеешь работать - иди учи людей как надо правильно работать!

большенство преподователей (в том числе и ХОРОШИХ) сами чистейшие ламеры

(449) не скажи, юзал, много чего клевого, но есть и ... как во всем, но запросы по сравнению с 7-кой - афигенные, правда ресурс жрет невменяемо - скуль-то встроенный

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

(448)

вот его рекомендации

3. Запускаем утилиту ConfigNT. Установливаем на закладке Memory Management галку в чекбоксе "Maximize Throughput for File Sharing". Тем самым мы дадим знать операционной системе сервера, что желаем, чтобы для использования файлов выделялся максимально доступный объем памяти. При данной настройке, операционная система не будет сбрасывать долго не используемые страницы оперативной памяти на диск, т.е. в виртуальную память.
4. Устанавливаем на той же закладке галку в чекбоксе "Use large system cache". Установка данной опции сообщит операционной системе сервера о том, что под кэширование дисков нужно выделить максимум оперативной памяти.
5. На закладке Other устанавливаем галку в чекбоксе "Update last access time on NTFS". Установка данной опции сообщит операционной системе сервера о том, что не следует обновлять время последнего доступа к файлам.


а теперь попробуй их выполнить для сервера 2000 и для 2008 (хотя-бы найди где эти опции), а про результат я вообще помолчу, ибо например большой кеш на на разных ОС по разному освобождает блокировки, тоесть вполне реально получить тормоза вместо ускорения

(451) да кто ж спорит, что много приятностей есть - все-таки, создавали гораздо позже файловых клюшек. Да и дорабатывают уже порядка 11 лет. в клюшках последние (до крайнего релиза математики) 7 лет только ошибки исправляли...

Народ а не лучшее ли средство оптимизации большой ДБФ-ной базы - переход на скуль?

(453) он тупо копипастит, не понимая смысла.

(455) он денег стоит. а в свете текущей лицензионной политики 1с - лучше на файлового снеговика...

(457) файловый снеговик - это чисто тестовая УГ, особенно с новыми типовыми рельсами.

снеговик - только трех звенный!

(457) в таком ракурсе - согласен: на скуль лучше не разоряться - сразу 8-ку брать ...

(455)Поверь, НЕТ :)
SQL - решает только проблему объема, но в минусе, уменьшается скорость.

+ Потом появляются потребности в скорости, но их решают только прямыми запросами к SQL :)

(459)Это верно. Если что, 8-ка может работать не только на SQL :)

(460,461) подробнее плиз ... на счет того что скулевая база тормзнутее аналогичной ДБФ-ной

(463) при прочих равных - значительно тормознее.

(460) SQL решает следующие проблеммы

1. Размер базы
2. Надежность базы
3. Не требуется переиндексации после кривого выхода (на больших базах может идти по часу и более)
4. SQL ный лог и возможность отката на любой моент времени
5. Возможность использования прямых запросов (в нормальном понимании это термина)
6. Возможность делать ХП и Тригеры
7. Возможность делать анализ скорости и блокировок средствами скуля

мало? могу еще накидать :)

(441) У Вас там поштучный учет изделий, наверное. Штампанули деталюшку - занесли новую строчку в номенклатурник. Еще бабульки какие-то наскипидаренные с ТСД на роликовых коньках носятся и в очередь к компу сливать информацию. Так на Вас никаких Ораклов не хватит. Готовый сценарий для фильма.
ЗЫ: шутю

(464) конкретизируй примерчиком, плиз
то что в скуле 2000 косяки есть - знаю, поэтому на 2005 перешли

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

(467) сравнения проводились еще году в 2004-2005. Ищи. мне лень.
а "косяк" 2000 с временными таблицами успешно обходится с 2004 года...

+(466) кроме того особо одаренные придумали схему - берут допустим 1000 изделий во время сезонных скидок (есть и 30-50%), потом по обычной цене - 100 изделий и пытаются возвратить все по-обычной, утрировано конечно, но единчное штрихкодирование изделий позволяет быстро принять товар по той цене, по которой он отпущен

(470) Увольняйся и едь в Москву. С чудаками на "м" работать - сам со временем чудаком станешь. Это заразно - по себе знаю.

(470) Вопросы возвратат тоовара по цене продажи и не больше чем было продано поднимались и решались не раз. Ваше решение самое изысканное.

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

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

+(474) да и оправдала она себя из-за больших объемов возвратов, потому как продукцию под реализацию отпускали, ну или когда на Выставки-ярмарки в Питер или Москву фуры отправляем, назад - 70% товара возвращается порой из которого. как правило 80% без упаковок.

(471) судя по некоторым его постам - ты несколько запоздал с предложением :-)
правда, насколько фатально - не знаю.

а вот в инете нашлось настоящее фото сикукана на работе: http://mimimi.on.ufanet.ru/freaks.gif

Приветствую всех! как тех кто симпатизировал мне, так и тех кто занимался открытым троллингом. Кстати, именно поэтому я не счел нужным комментировать все что было написано за время моего отсутствия))
---
Спасибо всем кто внес конструктивную критику. Благодаря вам статья действительно стала лучше. Обновленную версию выложил!

(478) вот согласись, что некоторые тут - непозитивные!

.. Вы думаете я страдаю манией величия? Я ей наслаждаюсь!

(427), все... можешь стреляться... терминалы многопиковая работа в узкий промежуток времени да еще в доки и с общим журналом - стреляйся! у мну пики с терминалов в онлайне чистом вообще нафиг никого не ждут и друг другу не мешают.. и тем более не лезут в журналы...

Так как особо не рублю в теме, то могу покритиковать только за опечатки:
"Советы по предварительной настройкА программного окружения"
))

(465)+ ты еще забыл упомянуть, при переходе на SQL, все что ты перечислил еще нужно допилить, дописать и отточить :)

+ По дефолту оно этого не умеет :)

+ Я про 1С

"Рекомендую безжалостно его удалять этот файл" ...

Да и вообще по тексту пунктуация страдает.

(478)Да без проблем... твоя статья отстой, жаль, что ты не внял нашим словам :)

Перечитал исправленную статью. Опять в недоумении. Не являюсь мегаспецом, но спорных утверждений слишком много.
Да и вообще не написано и десятой части действительно эффективных мер. Не надо было писать эту статью.
Может, автор что-то и знает. Но статья - отстой.

имха канеш - автор полез еще больше в дебри, еще больше запутался и пппц...