fscpsd

Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору gRONNIK Тут нюанс в том, что sql не ускоряет работу базы как таковую. Строго говоря, он даже немного замедляет её за счёт накладных расходов на обеспечение себя, любимого. Использование sql позволяет лишь устранить коллизии, неизбежные при работе файлового варианта, а также задержки, связанные с доступом к файлу базы данных, но тут встаёт вопрос: а из-за этого ли у вас там всё жутко тормозит? Мне кажется, что навряд ли, трём пользователям маловероятно такого добиться, разве что они синхронно осуществляют очень интенсивную работу с одними и теми же данными. Намного вероятнее, что у вас просто какой-то дефект в самой базе, либо накопились какие-то ошибки в данных или в самой структуре базы, после неудачной свёртки например, либо может какие-нибудь самописные кривые запросы мешаются (в старых УТ такое часто встречается), но это вам самому сложно будет диагностировать, на пальцах это не объяснить, тут специалист на месте нужен будет. Попробуйте разве что сделать полное тестирование-исправление, выполнить выгрузку и последующую загрузку конфигурации в пустую базу. Проверьте, что у вас используется новый формат базы данных 8.3.8, поэкспериментируйте с размером страницы (вплоть до 64к). Проверьте ещё SSD — они часто перед смертью могут очень сильно сбрасывать скорость работы, проверьте функционирование механизма TRIM, особенно если система старая. Антивирус попробуйте выключить, особенно если там какой-нибудь стоит какой-нибудь Kaspersky Internet Security с самой строгой политикой безопасности. Как вариант, если база очень старая, можете рассмотреть вариант перехода в новую чистую базу, с переносом текущих документов по актуальным периодам, а старая останется как архивная. Ну, и, наконец, можете взять и сами попробовать sql в тестовой среде, вдруг чудо случится, звёзды сойдутся и всё сразу летать начнёт, чисто теоретически такое тоже может быть, если механизмы оптимизации доступа к данным sql точно совпадут с проблемными местами вашей базы, хотя на практике это довольно-таки маловерятно, к сожалению. В общем, полно всяких вариантов, тут не угадаешь, особенно если система чужая и её полная история вам достоверно неизвестна. |