iScala 2.3

Мы еще не расхлебались с переходом на 2.2 SR2. А что официально было объявлено ранее, был какой-то документ?

Мдя, слышал что вышел… Пока переходить не будем… =)

aav писал(а):

Собираемся перейти в начале января. А тестовую конвертацию не делали? Индексы пересоздать не пробовали? И что говорит хотлайн? Кстати, а сколько у вас одновременно работающих пользователей?

Конвертацию сделали,на тестовом при работе одного пользователя работает нормально.Одновременно работают 300 пользователей.Есть еще внешние отчеты и внешние программы,использующие БД iScala
Хотлайн предположил,что недостаточно ресурсов.
На сервере 8ГБ оперативки,стоит SQL SERVER 2000 SP4,на SQL выделили 6ГБ памяти. В EM SQL Servera Current Activity обновляется очень долго.

У нас еле двигается, а загрузка ЦП сервера процентов 25.

aav писал(а):

Собираемся перейти в начале января. А тестовую конвертацию не делали? Индексы пересоздать не пробовали? И что говорит хотлайн? Кстати, а сколько у вас одновременно работающих пользователей?

Сами индексы не пересоздавали,запустили оптимизацию базы средствами SQL Servera

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

А какого размера сиквельный лог файл? Кстати, у нас иногда бывали ситуации, когда всё начинает умирать. Связано было с блокировками, проблемами с индексами, иногда непонятными проблемами с сервисами, которые лечили перезапуском сервисов или перезагрузкой сервера Вот и не знаю теперь, переходить на 2.3 или нет

А что там конкретно говорилось на момент вашего перехода?

Я думаю, что хотлайну надо передать пламенный привет. Насколько я понимаю, SQL Server 2000 эффективно использовать более 3 ГБ оперативной памяти не могет. Больше может использовать SQL Server 2005, и то только на 64-битной архитектуре. Вот тут некая ссылочка:
http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx#EYIAC
Мы сейчас, собственно, этим вопросом и занимаемся. В августе поставили 2.3, стало действительно больше тормозить. Сейчас взяли новый сервер, устанавливаем SQL 2005 на 64 бита, будем пробовать. Потом с результатами ознакомлю.

в документе : InstallDVD..\Readme\PRD-S23-089_iScala23_Release_Notes.htm

говорится следующее :

Server Hardware

Communities of up to 50 Users

We recommend having a dedicated server for the installation of DBMS and iScala 2.3.

Recommended configuration for communities of up to 50 users:

Dual Xeon — 3 GHz or better

2 GB RAM or more (4GB is preferable but not mandatory)

Hardware RAID-5 for OS, DBMS and iScala binaries (2GB for the DBMS and iScala installation)

Hardware RAID-5 with 6 spindles for iScala databases (at least 1GB for the initial installation)

Gigabit network connection

DVD ROM drive

Remote Operations of up to 20 Users

We strongly recommend the use of a dedicated server for remote operations (Terminal Services or Citrix Presentation Server).

Quad Xeon — 3 GHz or better

1 GB RAM per 10 users, but no less than 1 GB RAM

Hardware RAID-5 for OS and iScala binaries (2 GB for the iScala installation)

Gigabit network connection

Профайлером смотрим постоянно,знаем запросы, которые блокируют.Но,не запуская ничего внешнего,сама скала работает ужасно….Расход запаса по одной строке в заказе производится за 20 мин.

И что в это время делает SQL Server?

выполняет скальские запросы по отгрузке.

Запуская постоянно запрос:
—кто всех заблокировал
select getdate(), ltrim(str(spid))+’ ‘+ ltrim(rtrim(hostname))+’ ‘+
rtrim(loginame)+'(‘+rtrim(program_name)+’)’
from master.dbo.sysprocesses (nolock)
where spid in (select blocked from master.dbo.sysprocesses A(nolock) where blocked != 0)
and blocked=0

все время видим скальские блокировки типа
108 FIL3 ELIZ\fil3(iScala Power Platform 2.1 SP4 Beta)
где 108 процесс-простой селект ,выполняющийся за доли секунды
Раньше такие блокировки не высвечивались,т.к.обрабатывались быстро ….

aav писал(а):

А какого размера сиквельный лог файл? Кстати, у нас иногда бывали ситуации, когда всё начинает умирать. Связано было с блокировками, проблемами с индексами, иногда непонятными проблемами с сервисами, которые лечили перезапуском сервисов или перезагрузкой сервера Вот и не знаю теперь, переходить на 2.3 или нет ?

Если вы имеете ввиду скальский лог-файл, то он у нас в данный момент размером 31Мб,из них свободно 20МБ.При этом размер самой базы составляет 57ГБ, свободно -16ГБ .

Я почему спрашиваю, у нас была ситуация, когда при массовом обновлении лог вырос до десятков ГБ, место на диске почти закончилось и SQL сервер почти "лег".
Как в том анекдоте: тряпочкой протирал? — да, ногой колеса пинал? — да. Ну, тогда и не знаю

На последних семинарах рассказывалось, что для статусов заказов на продажу можно будет не только запрещать отгрузку или печать разных документов, но и запретить редактирование строки. Посмотрел текущий хотфикс, этого ещё нет, а жаль… Пока искал, набрел на возможность задавать/запрещать просмотр/редактирование/удаление заказов на продажу отдельно для своих и для всех, т.е. можно сделать, что и список заказов и их редактирование для какой-то конкретной роли будет настроено так, чтобы показывались только свои заказы, а для другой роли — все. Жаль только, что идея, как всегда, реализована наполовину. Нельзя видеть не только свои заказы, а "свои" в рамках какой-то группы, что было бы весьма полезно, например, в нашем случае, когда есть специализация продавцов на продукции отдельного производства, соответственно, заказы введенные продавцом № 1 должен видеть, как сам продавец, так и складской работник производства № 1, а заказы продавца № 2 он видеть не должен, равно, как их не должен видеть и продавец № 1

Есть какие-нибудь результаты? Мы переходим через 2 недели, очень не хочется попасть в ситуацию, когда всё станет "умирать". Кстати, интересно, может ли дело быть в 2000 SQL сервере? Мы-то уже на 2005-м…

Как раз заканчивается первая неделя после перехода на новый сервер (железо+ 64-битный SQL 2005). Пока (тьфу-тьфу) полет нормальный. Эффект весьма заметен. Увеличение скорости на некоторых тормознутых отчетах (типа "Выборочный отчет по должникам") и процедурах (закрытие кучи заказов на продажу) более чем на порядок (!). Настораживает оставшаяся некоторая "интерфейсная" тормознутость, но, во-первых, она не очень большая (хотя больше чем в 2.2), а, во-вторых, сама Скала стоит у нас на другом сервере, к которому тоже есть вопросы. Будем смотреть дальше.

То есть Скала стоит на 32-битном сервере? Обращается к 64-битному SQL’у и всё нормально? Пока не пришли новые сервера мы планируем временно реализовать такую же схему, точнее почти такую же, ибо у нас 2 Скалы. Одна будет вместе с SQL’ом на более-менее новом 64-битном сервере, вторая на старом 32-битном, а базы данных от обеих — на новом. Сейчас тестируем, вроде работает.

В качестве возможных вопросов к производительности iScala 2.3 по сравнению с 2.2 — я заметил, что много новых полей понадобавляли — причем некоторые из них аж по 150 символов длиной, естественно, база данных должна подрасти. Плюс, как мне пояснили на хотлайне, много новой функциональности, которая, возможно, и подтормаживает…

Да, здесь без проблем.

Может быть, может быть…