Погода: -12°C
  • Доброе время суток. народ подскажите не кто не сталкивался с переходом с SQL на DB2. Или возможно кто-нибудь тестировал данное ПО. Интересует прежде всего насколько лучше или хуже работает связка db2 c 1c по сравнению с SQL c 1c.

  • 1. О какой именно 1С идет речь?
    2. Зачем переходить хотите?

  • 1) речь идет о 1с 8.1 Скорее всего УТ но возможно и УПП.
    2) были на семинаре IBM. там рассказали что база в db2 может уменшиться в размере примерно на 50 %. У нас просто проблема УТ разрастается за 1 год до 150 Гигов. Возможности покупать хранилище особой нету.

  • А сколько документов за год в базе?
    Конфига типовая или нет?

  • конфигурация не типовая(была взята типова и в ней отключенно все лишнее. Нечего не переписывалось и не дописывалось). Бьются только реализации. и поступления больше нечего. Все остальное ведеться в отдельной базе. Насчет документов пока не владею такой информацией.

  • примерно 200 000 в месяц документов

  • "Бьются только реализации. и поступления больше нечего" - тоесть, взаиморасчеты так и висят? Может, стоит все-таки подправить конфигу, чтобы убрать эти лишние движения?
    Так как 200 тыс. доков в меся не должны давать такой большой прирост размера базы. Если, конечно, в каждом документе не по тысяче-другой строчек.
    И ваша проблема с размером автоматически отпадет.
    Кстати, а что за организация, если не секрет?

  • Что значит "скорее всего УТ но возможно и УПП". Посмотреть Помощь-О программе не судьба?

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • Те, кто ставят 1С УПП, на свое железо потом не смотрят вообще, ибо на фоне стоимости информации в базе, винты расходный материал. Более того, такой рост объема базы прогнозируемый. Это изначально траты на оборудования значительные: покупают производительные серваки, СХД и вперед, а винты докупать коппейки.

  • п.9

    нет возможности. поскольку еще на этапе выбора.

    Исправлено пользователем Barlog (17.08.09 09:33)

  • п.9
    Это понятно. Вот и ищем варианты. Поскольку базу надо будет держать как минимум лет 5. для аналитики и статистики. на производительные сервера начальство врядли денег выделит. да и стаким ростом надо будет их каждый год модернезировать. А то SQl не прожует. а производство круглосуточное.

    Исправлено пользователем Barlog (17.08.09 09:33)

  • Подумайте, может вам проще свою конфу сделать под заказ - оптимизированную специально под ваши задачи. Оно может дешевле выйти. DB2 исключительно дорогая игрушка... наверное самая дорогая СУБД.

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • А ты знаешь того, кто сможет взяться за такую работу? На объемы данных глянь.

  • В ответ на: нет возможности. поскольку еще на этапе выбора.
    Не понял ? Выбора чего ? Вы же говорите, что работаете уже в определенной конфигурации.

  • п.9

    1) 200 тыс док. /мес многовато, однако:улыб:
    Тут надо планировать систему по принципу фронт-офис, бак-офис
    Если конфы стандартные, то и стандартная тулза от УТ подойдёт

    2) если уменьшают объём, то вероятно, за счёт быстродействия (из общих соображений). На рабочей системе я бы не стал эксперименты ставить

    NSK & SIB

    Исправлено пользователем Barlog (17.08.09 09:34)

  • В ответ на: 1) 200 тыс док. /мес многовато, однако:улыб:
    Вполне нормальный объем для скулевой семерки. Проверено на гораздо больших объемах.
    Естественно, конфига должна быть полностью самописной. Туповые на таких объемах, к сожалению, не канают.

  • п.9

    Сейчас все работает в разных системах. Причем половина не 1с. И нету оперативных данных как таковых. И те самописные программы кто писал то же уволился. Вот и стал выбор перейти на 1с 8.1.
    Поэтому и выбор. А тестируем пока на УТ общий объем. Так сказать пааралельно доки бьются.

    Исправлено пользователем Barlog (17.08.09 09:34)

  • В ответ на: А ты знаешь того, кто сможет взяться за такую работу? На объемы данных глянь.
    Смогут взяться многие. А вот смогут ли довести ее до конца - не знаю:улыб:

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • А что Postgresql никак?

  • В ответ на: Смогут взяться многие. А вот смогут ли довести ее до конца - не знаю:улыб:
    Под словом "взяться" я, естественно, понимаю взяться за работы и успешно их выполнить. А не только взяться и проколоться:улыб:Я, например, от таких рабоот на восьмерке отказался. Не верю я в чудеса.

  • В ответ на: А что Postgresql никак?
    Очень неудачная шутка...

  • А никто не говорит что непременно должна быть 8-ка. Можно и 7-ку с 1С++ и прямыми запросами SQL

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • К сожалению, на сколько мне известно, как раз так и говорят - "Только восьмерка".
    Или где-то есть другая информация?

  • Я так понял что просто 8-ка обсуждается в числе прочих вариантов.

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • Из этой веточки понял или общался с ними вне форума?

  • Из ветки

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • В ветке не вся информация.

  • Только 8.1. Это Желание начальства. Планируется перевести все конторы на нее. Одна из контор уже работает и деньги за ту работу уже отданны. Переделывать заново некто не даст. А вот что из 8.1 ставить это уже наш выбор. Либо УПП и все там и бух и кадры и производство и торговля. Либо все разбивать.

  • Ну тогда готовьтесь отдавать много-много бабла...

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • Отдать бабло начальство готово. Но что бы 100% что будет внедренно.

  • п.9 А вот это дааалеко не факт что будет сделано.

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

    Исправлено пользователем Barlog (17.08.09 09:35)

  • В этом и загвостка. ИТ-отдел понимает. А начальство не сильно. Оно думает сейчас франчи а потом своими силаси. И вытенем. :хехе:

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

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • Ну я могу такое делать. На свои разработки (если туда кроме меня ни кто не лезет) дам вечную гарантию. Расчет возможен после реальных результатов.

    Вот только сдается мне (промелькнуло тут), что если руководство не хочет вкладываться в развитие, то о чем вообще говорить.

  • Извините, но почему-то буквально в каждом предложении какой-то, ну, непофессионализм чуствуется...
    Поясню:
    - не верю, что профессионал даст "пожизненную" гарантию. Гарантию на что? Что "всю жизнь" будет работать с приемлимой скоростью? Или что-то другое?
    - в одного такие проекты никогда не делаются.
    - "Расчет возможен после реальных результатов" - Вы готовы год-полтора работать бесплатно? Ну не верю.
    Или, просто, не до конца оценили массштаб работ?
    Ни коим образом не хотел обидеть. Всё выше сказанное - ИМХО.

  • п.9
    -вечную даю на то, что это будет работать правильно.
    А далее нужно смотреть. Что и как. Я даже по 7.7 запросы и все остальное всегда оптимизировал. Смотрел в отладчике замеры и оптимизировал, чтобы это все это формировалось с хорошей производительностью. Но если это будет мой косяк, то устраню за свой счет.
    -Если я почувствую, что я не вытяну, то я просто не соглашусь дать договор на работу. Мне косяки ненужны. Репутация дороже стоит.
    - Когда в 2006 я приехал в Новосиб, то на вопрос: Какую зарплату хотите на испытательный срок???
    Я отвечал : Можем бесплатно попробовать. Но если я Вас устрою, то за испытательный Вы мне выплачиваете в полном размере.
    Да согласен и на год и на полтора, и два. Только условие. Я то работу с собой заберу. И обязательно аргументированный ответ. У меня все юридически прописывается. Да и договор я официальный даю.

    А я не из обидчивых. Просто некоторых я игнорирую.

    Исправлено пользователем Barlog (17.08.09 09:35)

  • Чуствую, что все-таки Вы не до конца прониклись масштабами проекта...
    На всякий случай - обратите внимание на документообот - 200 тыс. доков в месяц.
    Плюс, там еще много ньюансов. Я, просто, в свое время ТЗ видел. Поверьте, там далеко не все так просто, как кажется из данной ветки.
    Кстати, гарантию "что это будет работать правильно." каждый уважающий себя прогер и так дает. Сдесь, помимо этого, требуется еще и "очень быстро" хотя бы 5 лет. Хотя, я бы закладывался на 10-12 лет. Без "обрезания" базы.

  • При нежелании руководства вложиться в инфраструктуру, на которой будет всё это "крутиться" перспективы проекта непонятны.

  • Вложить готовы. Но не готовы каждый год вкладывать. Так сказать не готовы к ежегодной модернизации. Я внедренцы говорят. Сейчас покупайте мощное оборудование. Мы же со свой стороны видим что год отсилы 1,5 оно будет работать нормально. А дальше. а дальше нам советуют модернизируйте. Так вот дальше нам не дадут денег. И всех собак спустят уже на нас. А если учеть что и внедрение явно будет идти не 1 год. То перспективы не сильно жизне радостные.

  • Покупайте оборудование, которое будет работать не 1,5 года. проблема в чём? В проектировании? В аргументации?
    Делаете официальный запрос внедренцам: "просим предоставить информацию о конфигурации оборудования, обеспечивающего работу внедряемой Вами системы на срок не менее 5 лет".
    Это так, грубо.
    И проект договорчика об финансовой ответственности внедренцев за предоставленную информацию о конфигурации оборудования.
    Понадобятся вложения в течении 5 лет - за счёт внедренцев.

    А вообще понять не могу?!
    На рынке не существует оборудования, которое будет "тянуть" 5,7,10 лет? Есть. И то, что Вы пишите "оно только 1,5 года будет работать нормально" - это вопрос скорее к Вам.

  • п.9
    В чем неудачна то? Не спорю, DB2 монстр еще тот, но 200 тыс. документов в месяц Postgresql потянет легко. И там и там нужно правильное проектирование. Плюс железо. А без него и DB2 не в радость будет. Особенно DB2.

    Исправлено пользователем Barlog (19.08.09 11:44)

  • 200 000 доков в месяц это, грубо 6,67 000 документов в день. 275 документов в час, 4 документа в минуту. Нифа себе, может немного бизнес-процессы создания/формирования документов им подправить? Для начала.

  • не потянет Постгре 200 000 документов в месяц. если только у документов нет табличных частей то может быть.
    плюс у постгре есть очень большой недостаток - при смене релиза ядра надо менять версию постгре. Поэтому в свое время с постгре на MS SQL перешли

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • в очень крупной торговой сети вполне может быть

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • ну тогда и деньги должны найтись на проект. я так понимаю стоимость собственно 1С по сравнению со стоимостью внедрения и стоимостью оборудования будет крайне мала...

  • п.9

    Все бы хорошо. просто если не смогут отгрузить компания понесет колоссальные потери.
    И не важно будет кто внедрял. Полетать наши головы. Это рас.
    Во вторых я писал что база за год одних только реализации примерно получается 150 гигов. Вот теперь представьте за 5 лет 750 гигов. И хотябы один из экономистов или из Аналитоков. Решил собрать продажи по месяцам за 5 лет. А теперь вопрос какие надо сервера. Чтобы в это время 10 человек по приемки заказов могли забивать документы. И 10 человек отгружать товар.

    Исправлено пользователем Barlog (20.08.09 06:35)

  • п.9

    Стоимость 1с в данном случае будет пыль. на которую некто даже смотреть не будет.

    Исправлено пользователем Barlog (20.08.09 06:35)

  • п.9

    Работал я как то в конторе крупной, у них база по 7.7 за год разрасталась до 45 гигов. И ни че. Работали, и отчеты за предыдущие годы нормально формировались. И отписка нормально велась.

    Исправлено пользователем Barlog (20.08.09 06:35)

  • Тут походу единственный вариант - это тот который я в личку писал.

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • В ответ на: . А теперь вопрос какие надо сервера. Чтобы в это время 10 человек по приемки заказов могли забивать документы. И 10 человек отгружать товар.
    в идеале надо будет иметь два как минимум, по стОимости - каждый будет 200-250т.р. минимум + всякие ИБП + система архивирования и т.д. и т.п. + клиентские компы... сумма без учета софта вылезет немаленькая....

    Вне ассоциаций, вне конкуренции...

  • Э... Не многовато? Ведь, всего 20 пользователей...

  • В ответ на: Э... Не многовато? Ведь, всего 20 пользователей...
    ну немного ошибся, сумма будет ниже, примерно получается все так: 2х процессорный сервер HP с 4 винтами 500gb+8Gb+raid примерно выходит $3500 если добавить виндовс 2008 на 25 клиентов, то общая сумма за один комплект возрастет до $7100, еще UPS нужен будет нормальный...

    Да, мое замечание по задаче - при таких объемах я бы базы разделил, одна основная крутится на одном серваке, а текущие документы вводятся на втором и регулярно за определенный период, например сутки-двое, данные из "оперативной" базы переносятся в основную :миг:ну это как вариант:улыб:

    Вне ассоциаций, вне конкуренции...

  • Я в своих прикидках стоимость ПО не учел. Тогда да, скорее всего, соглашусь с первой цифрой.

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

    п.3

  • Какие надо сервера?
    Этот вопрос задавайте внедренцам. На официальном бланке предприятия.
    Вы хотите у форума проект по железу получить? Так что-ли?

    Ну нарисуют Вам конфигурацию, Вы с ней к директору придёте "вот мне тут на форуме насоветовали"? Возьмёте на себя такую ответственность?

    "колоссальные потери"... если руководству предприятия понятны цифры потерь за час/сутки и т.д., то проблем с понимаем сумм на реализацию проекта быть не должно.

    На Ваше "рас" - занимайте более чёткую и последоваательную позицию перед руководством такого плана:
    "Я считаю, что рекомендованная конфигурация не сможет обеспечить нужные нам .... Для реализации поставленных задач требуется то-то...." и служебкой директору.

    на Ваше "два"
    никаких проблем с технической точки зрения не вижу. Тут писали, что не нужно две базы. Смотря как подходить к решению задачи.
    Должна одна база для продажников, бухгалтеров -тех кто работает с вводом/выводом первички.
    И копия базы - например ежедневно "поднимаемая" из бэкап на другом серваке, с которой будут "играться" экономисты и аналитики. Чтобы при запуске расчётов не "пригружать" производительность основной системы.

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

    Но я уже повторяюсь.

  • В ответ на: "колоссальные потери"... если руководству предприятия понятны цифры потерь за час/сутки и т.д., то проблем с понимаем сумм на реализацию проекта быть не должно.

    никаких проблем с технической точки зрения не вижу. Тут писали, что не нужно две базы. Смотря как подходить к решению задачи.
    Должна одна база для продажников, бухгалтеров -тех кто работает с вводом/выводом первички.
    И копия базы - например ежедневно "поднимаемая" из бэкап на другом серваке, с которой будут "играться" экономисты и аналитики. Чтобы при запуске расчётов не "пригружать" производительность основной системы.
    Соглашусь. Особенно с разделением баз. Только грамотно настроить, и проблем с обменами не будет.

  • Базы с таким небольшим, в общем-то, документооборотом прекрасно работают и без "разделения"...

  • В ответ на: А если смотерьть на конфигурации FaceOFF - с таким количеством "шпинделей" Вы не получите достойной производительности дисковой системы.
    А вот сколько - вопрос к "внедренцам", которые исходя из своего опыта выполнения подобных проектов могут дать рекомендации. Читаем первый абзац.
    Но я уже повторяюсь.
    Через меня прошло столько скомплектованных/ сконфигурированных серверов за последние лет 10 - Вам даже не снилось... я привел примерную конфигурацию, в конкретику на тему как и что будет сконфигурировано даже не вдавался, дабы не учить некоторых представителей контор псевдо-внедренцев...
    И как можно оценивать производительность системы, не зная как она сконфигурирована :dnknow:
    Так что не надо ля-ля...если есть конкретные спорные моменты - озвучьте, только в привате - не хочу здесь размещать инфу...
    По поводу проектов по железу и софту - я не скрываю, что оказываю по комплексной автоматизации и если мы заключаем договор письменный или устный с заказчиком, то естественно я ему предоставляю полную смету с аргументацией что надо, как и почему...
    А чуть выше по поводу количества жестких дисков, их вообще пять шт. надо.. почему столько - советую поучить мат.часть по организации рейд-массивов:улыб:

    Вне ассоциаций, вне конкуренции...

  • В ответ на: Базы с таким небольшим, в общем-то, документооборотом прекрасно работают и без "разделения"...
    да, конечно, но разделение баз (как они должны правильно взаимодействовать я расписывать здесь не хочу по той же причине, какая озвуче чуть выше по железу) позволит обеспечить достаточную отказоустойчивость системы, так как при таком объему ввода документов даже простой в течение 6-12 часов тянет за собой большие убытки...

    Вне ассоциаций, вне конкуренции...

  • Пипец. За мой 14 лет в ИТ тоже дохрена проектов было и что? Пиписьками мериться будем?

    А по поводу организации RAID советую Вам матчасть подучить.


    RAID 0 - min 2 spindel
    RAID 1 - min 2 spindel
    RAID 5 - min 3 spindel
    RAID 10 - min 4 spindel

    http://en.wikipedia.org/wiki/RAID

  • В ответ на: Пипец. За мой 14 лет в ИТ тоже дохрена проектов было и что? Пиписьками мериться будем?
    en.wikipedia.org/wiki/RAID
    Мериться с вами не собираюсь, все написал выше,
    а Вы продолжайте вводить в заблуждение народ дальше... и Вам на будущее - не стОит давать народу ссылки на подобные ресурсы - там некорректной информации в разы больше чем правды...

    Вне ассоциаций, вне конкуренции...

  • господа а вы про кластеризацию не забыли? такой документоборот не редкость, да проблемы могут быть - это если не продумать сразу, но все решается и с большим документооборотом. Главное здесь что скорость записи не подкаала. Если уж совсем плохо - то можно сделать так называемое "частичное" проведение. Но повторюсь решабельно и на отличную оценку.

  • ТС говорил, что "сторадж" брать не собираются. Скорость записи - под вопросом. Либо сервак с большой внутренней полкой брать, шпинделей на 10 и "вперёд с песней".

    при грамотном планировании и без кластеризации прожить можно.

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

  • п.9
    про стораж даже намека нет. я говорил о кластеризации 1С и СУБД. И если не большой секрет откройте тайну как грамотное планирование на кластеризацию влияет

    Исправлено пользователем Barlog (21.08.09 14:11)

  • рассказываю:
    грамотно запланировав нужные конфигурации оборудования, для работы спецуального программного обеспечения, закупили енто оборудование. оборудование обеспечивает требуемую для бизнеса доступность в режиме 24х7х365 на протяжении 6 лет. Без кластеризации.
    До данным логов доступность от 99,99, до 99,9. Ибо серверов несколько и спецуального программного обеспечения - несколько.
    Бизнес - доволен.
    И без дополнительных вложений в это оборудование на протяжении 6 лет.

    Грамотное планирование повлияло на кластеризацию. Её нет.

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

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

  • п.9 Если честно это только упрощает:улыб:и действительно для кого это мы :а\?:

    Исправлено пользователем Barlog (21.08.09 14:12)

  • Посмотрел я на сайте 1С пример внедрений. Определённо у организации ТС проблемы с пониманием задач и реализацией проекта. Ни у кого таких объёмов нет.
    Как размера базы, так и кол-ва документов. Что-то в бизнес-процессах организации не так.

    Картинка в аттаче.

  • А Вам не приходит в голову, что есть более крупные предприятия, чем киоски на рынках? Предприятия, в которых 4 000 отгрузок в день - это норма?
    Уж извините за резкость...

  • Аттач-то смотрели? или так "постебаться"

    На первой строке Аконит.
    это млять ларёк что-ли?
    С максимальным чилсом пользователей 370?
    А размеров базы 174 Гига.
    http://v8.1c.ru/overview/techparams/akonit.htm

    Резкий Вы наш.

    Рассмешили.

  • Тогда я несколько не понял Вашего предыдущего поста. ТС заявляет гораздо меньший документооборот.

  • В ответ на: Доброе время суток. народ подскажите не кто не сталкивался с переходом с SQL на DB2. Или возможно кто-нибудь тестировал данное ПО. Интересует прежде всего насколько лучше или хуже работает связка db2 c 1c по сравнению с SQL c 1c.
    Вот свежак от 1С:БИТ внедрение на DB2 . причем там бесплатная версия, которая 2 Гб памяти всего использует. У вас пользователей сколько? Возьмите workgroup - она до 16 гигабайт оперативки уже испольует и посмотрите что и как. Берете триал версии 9.7 с сайта IBM и вперед. Только db2set DB2_WORKLOAD=1C не забудьте после инсталляции сделать:улыб:

  • Мы проводили замеры, по которым можно сказать, что для документооборота 200 000 док/мес (1000 док/час) в 1С 8.1 (УПП) вполне может хватить и бесплатной DB2 Express-C, особенно если речь идет об оперативной работе.

  • А можете описать, как Вы производили эти замеры?
    Мои тесты, например, показали, что типовая УТ под скулем тихо мирно сдувается уже на первой сотне тысяч документов.

  • У меня такое ощущение что это тупой пиар.
    Два джуниора с одним сообщением у каждого подняли топ...

    Осторожнее с травой!
    Если хапнешь много дряни
    Увезут тебя с собой
    Злые инопланетяне

  • Я даже догадываюсь откуда ноги растут.

  • Не должно такого быть, что-то не так.
    Как-то делал тестовую базу УПП на 6 миллионов документов (100 гигов получилось). Заполнилась она роботами где-то за полторы недели и жила вполне адекватно. Только блокировки в управлемый режим перевел, и, понятно, проведение по партиям из оперативного режима убрал.
    Поэтому не считаю размер базы критичной величиной для проведения тестов производительности.
    Замеры проводили примерно так:
    накатили на УПП Тест-центр, подняли нужное количество виртуальных пользователей (скажем,100), задали им минимальный интервал ввода минуты в 3, запустили, типовой сценарий Закупки,Продажа, производство в УПП, скажем, на час.
    100 * (60/3) = 2000. Реально объем минимум вдвое больше, потому что у пользователя цикл документооборота не из одного документа состоит.
    За неделю тестов документов каждого используемого вида в базе > 10 000 точно, не сто тысяч, конечно, но и не единицы.

    Исправлено пользователем fev_trsoft (26.09.09 00:43)

  • Извините, не верю.

  • >типовая УТ под скулем тихо мирно сдувается

    в ЦУПе не смотрели - из-за чего?

  • Нет, не смотрел. Руки пока не дошли. Целью эксперимента было просто помотреть поведение типовой УТ на хоть каком-то объеме данных. Причины чуть позже выяснять будем, как времени немного появится.

  • Кстати говоря. Все-таки, возможно, мы некорректно сравниваем УТ и УПП. Именно про УПП была информация, что с 1.2.15 она была очень сильно доработана на тему производительности и серьезно с тех пор на эту тему мониторится. А про УТ у меня такой информации нет.

  • п.9
    А вы попробуйте сами:улыб:Express-C денег не просит, возьмите с сайта 1С и загрузите в нее .dt-ник.

    Исправлено пользователем Barlog (01.10.09 14:20)

  • Почитайте веточку внимательно. Я на УТ-шке пробовал. Результаты, мягко говоря, не впечатлили.
    Плюс, есть 2 живых примера УПП перед глазами. Не взлетают типовые конфиги от 1С на больших объемах. Увы.

  • п.9
    Не понял на какой версии DB2 вы все это пробовали?

    Исправлено пользователем Barlog (01.10.09 14:18)

  • Я где-то писал про DB2? Ух ты...:улыб:

  • п.9

    ВО! Попробуйте поставить DB2 и посмотрите.
    В ней есть один интересный алгоритм, который позволяет более эффективно строить планы запросов. План запроса перекомпилируется после того, как получены его результаты. 1С этот режим по-умолчанию использует.

    Исправлено пользователем Barlog (01.10.09 14:19)

  • Есть у меня подозрение, что кривые запросы типовых конфигураций это не исправит...
    Повторюсь - только подозрения. Не проверял.

  • Ну у DB2 оптимизатор хороший.:улыб:Призван исправлять кривые запросы на более правильные.

Записей на странице:

Перейти в форум

Модераторы: