proNovell

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

Честно - не знаю даже что там оптимизировать.
Есть опыт работы с БД на фоксе на 4.11 сп6-8, 5.0, 5.1 сп 3-5, 6.0 сп3.
Количество пользователей до 150 одновременных конектов к каждой базе.
На версиях 4-5.1 вообще никаких проблемм не наблюдалось.
На 6-ке работает, но только на традиционных томах, на НСС-ных не получилось (пользователь блокирует один из файлов и БД начинает разъезжаться)...

гм... ну допустим
1. стоит ли включать Oplock?
2. какое значение параметра reconnectlevel?
3. стоит ли включать packetburst?
и т.д...

oplock включать не стОит, если с базами работает больше одного пользователя.
reconnectlevel - определяет действия клиента при потере соединения (число попыток восстановить соединение и т.д.)
packetburst - пусть будет, хуже от него не становится.
Какая там вообще может быть оптимизация? Разве что компрессию на томе убрать. Если базы большие и индексы к ним тоже - можно заранее turbofat вырубить. Если это что-то размером с 1С - то увеличить кол-во одновременно открытых файлов клиентом.

ну по поводу реконнектлевела был разговор, что например при реконнектлевел=3 медленнее чем при реконнектлевел=1...
почему выключать oplock?
а вот с packetburst наоборот гдет были предложения отрубать, потому как медлеенно...
вот компрессия это тоже параметр интересный... ибо причем тут компрессия? она ж не на лету производится как в вин...?
имеет ли смысл включать TTS для этих файлов?

oplock выключать, т.к. рано или поздно получишь что-то типа "станция такая-то превысила свой интервал..." (что-то типа того) и порушенные индексы.
packetburst включается по умолчанию и служит наоборот для увеличения скорости сетевого обмена.
Компрессия - если базы когда-нить будут сжаты, получишь тормоза ещё те. Компрессия производится (если не ставить атрибут compress immediatly) по расписанию - обычно это ночью. Кроме времени на расжатие файлов ещё и грузит процессор.
А по TTS никто мне на аналогичный вопрос толком никто не ответил (см. ветку "стОит ли защищать базы с помощью TTS в моем случае).

Alex Korneliuk писал(а):packetburst включается по умолчанию и служит наоборот для увеличения скорости сетевого обмена.

А по TTS никто мне на аналогичный вопрос толком никто не ответил (см. ветку "стОит ли защищать базы с помощью TTS в моем случае).

packetburst - автоматом увеличивает количество усланных пакетов до того как придет пакет-подтверждение об успешной доставке. По умолчанию: один посыл - один ответ.

TTS на каждый акт записи стаается сделать пометку о том что куда писали. Да и по старой памяти софтина работающая с tts должна быть совместима с этим tts. Чтобы сообщать серверу о том когда у нее начинается транзакция, а когда заканчивается. Иначе, на сколько я помню механизм tts не работает.

Vitaly G. писал(а):

Alex Korneliuk писал(а):TTS на каждый акт записи стаается сделать пометку о том что куда писали. Да и по старой памяти софтина работающая с tts должна быть совместима с этим tts. Чтобы сообщать серверу о том когда у нее начинается транзакция, а когда заканчивается. Иначе, на сколько я помню механизм tts не работает.

Это теория. Причем как мне отвечали в той самой ветке умные люди - софтина, не заточенная под работу с ТТС не сможет нормально работать, т.к. базы будут постоянно лочиться одним пользователем, не давая другим возможности что-то изменить (примерно так мне ответили). Я пытался проверить на практике и никаких отличий от работы без атрибута transactional на ДБВках не заметил (правда проверялось только при работе 2ух пользователей).

имеем...
небольшая база в 200мб... 5 клиентов вин98+клиент3.32сп1, сервер нетваре 4.11сп9... LRU не мение 15минут... сеть 100мбит... винты скази 40мб трансфер... утилизация процессора мение 5%... попадания в кеш более 95%...

проблема...
первый пользователь заходит на ура... открывает около 50 файлов
второй и последующие в этуже базу входят раз в 10-20 дольше... :(((

как решить? на что обратить внимание?

Где можно почитать про оптимизацию TTS?

Larico писал(а):На 6-ке работает, но только на традиционных томах, на НСС-ных не получилось (пользователь блокирует один из файлов и БД начинает разъезжаться)...

А можно с этого места по подробнее. А то у меня тоже фоксовая база крутится на 6-ке с ННС-ными томами. Решали проблемы путем длительных извратов, типа как автоматическое проставление атрибутов "совместное использование", обновление клиентов, установки SP, даже софт переписали, чтоб базы сначала себе локально копировал, вносил изменения, а потом на серваке исправлял базы и индексы. Но раз в месяца 1.5...2 проблемс иногда всплывают. Может стоит перейти на традиционные тома? Оправдан ли будет этот переход?

Сервер NW6SP5 NSS,
Параметры oplock
SET LEVEL 2 OPLOCKS ENABLED = ON
SET CLIENT FILE CACHING ENABLED = OFF
Рабочие станции Win2000SP4/XPSP1 клиент 4.83SP2/4.9SP1
Баз и клиентов не много, но одна из баз приблизительно на полтора миллиона записей.
Ни одной из вышеперечисленных проблем не наблюдается.

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

я бы вашим программистам поставил памятник.