Переодически подвисает Фин Книга Операций

[rmv]

Сходил по ссылкам.
Без обид - зря потерял время.
Нигде не встретил ситуации когда до оптимизации calcfieds и calcsums возвращал "неточное" значение X, а после оптимизации "точное" Y. Высылайте файлик

[RedFox]

Цитата:

Сообщение от rmv

Сходил по ссылкам.
Без обид - зря потерял время.
Нигде не встретил ситуации когда до оптимизации calcfieds и calcsums возвращал "неточное" значение X, а после оптимизации "точное" Y. Высылайте файлик

Малеха недопонял что именно вы искали, но файл выкладываю

+
The following is an excerpt from SQL Server Books Online:
When you create an index in the database, the index information used by queries is stored in index pages. The sequential index pages are chained together by pointers from one page to the next. When changes are made to the data that affect the index, the information in the index can become scattered in the database. Rebuilding an index reorganizes the storage of the index data (and table data in the case of a clustered index) to remove fragmentation. This can improve disk performance by reducing the number of page reads required to obtain the requested data.

[rmv]

Спасибо за книжку. С удовольствием прочел.
Цитирую Вашу фразу:

Цитата:

Да и на SQL будете получать более точные значения в вычисляемых полях.

По простоте душевной я понял что после до оптимизации calcfield возращает значение X, после оптимизации "более точное" значение Y. Или вы что то другое имели ввиду?

[RedFox]

Цитата:

Сообщение от rmv

Спасибо за книжку. С удовольствием прочел.
Цитирую Вашу фразу:

По простоте душевной я понял что после до оптимизации calcfield возращает значение X, после оптимизации "более точное" значение Y. Или вы что то другое имели ввиду?

Этой фразой я хотел сказать, что под SQL вычисляемые поля созданы с помощью спец таблиц. В 2000 версии (за 2005 не скажу) был такой баг с вычисляемыми полями, который не совсем корректно давал результаты. Точные результаты можно было получить либо спустя некоторое время (кол-во времени в каких-либо единицах не знаю), либо переформировав ключи.
Ссылки на форум SQL сейчас тоже не привету - с ходу не нашел куда сохранил.

[Arshak]

Коллеги, на ночь глядя посмотел умную презентацию про оптимизацию под SQL. если честно очень понравилось но появилось пара вопросов
1 риторический- если в микрософте все знают то почему не делают сразу а оставляют все на откуп партнрам..
мне кажется риск ошибки партнера в этой тонкой сфере выше чем у разработчика
2 мне интересен такой вопрос который тут уже поднимался про SETCURRENTKEY, насколько я понял это функция на SQL используется только для сортировки( при чем судя по презентации, уже после выборки данных) в связи с этим вопрос насколько резонно заводить ключи только для сортировки?
так же меня заитересовало утверждение что иногда суммироание с прямой выборкой быстрее чес с использованием вычисляемых полей- вопрос может стоит сократить или совсем отказаться от навиженовских вычисляемых полей? при этом, насколько я понял, имменно наличичие вычисляемых полей, да еще при большом индексе, содает серьезные тормоза при учете.

3 мне очень понравилась идея отключать SQLIndex для некоторых ключей,
вопрос- я правильно понимаю что если отключить SQLIndex то система при SETCURRENTKEY формально увидит этот ключ но при запросе на SQL этот факт будет проигнорирован но система не вылетит в ошбку об отсутствии ключа?
инресно будет выслушать мнение отечественных специалистов! а то боюсь по аглицки я не все правильно понял

[RedFox]

Цитата:

Сообщение от Arshak

Коллеги, на ночь глядя посмотел умную презентацию про оптимизацию под SQL. если честно очень понравилось но появилось пара вопросов

Я не большой специалист в данной области, но попытаюсь вставить свои 5 копеек.

Цитата:

1 риторический- если в микрософте все знают то почему не делают сразу а оставляют все на откуп партнрам..
мне кажется риск ошибки партнера в этой тонкой сфере выше чем у разработчика

На все есть бюжет и решение сверху, как мне кажется.
Недавно видел доку, где писалось, что 5 СП1 вроде как вообще переделаны SIFT. Как иногда любят говорить - всему свое время. А вот когда оно будет - не очень понятно к сожалению.

Цитата:

2 мне интересен такой вопрос который тут уже поднимался про SETCURRENTKEY, насколько я понял это функция на SQL используется только для сортировки( при чем судя по презентации, уже после выборки данных) в связи с этим вопрос насколько резонно заводить ключи только для сортировки?

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

Цитата:

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

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

Цитата:

3 мне очень понравилась идея отключать SQLIndex для некоторых ключей,
вопрос- я правильно понимаю что если отключить SQLIndex то система при SETCURRENTKEY формально увидит этот ключ но при запросе на SQL этот факт будет проигнорирован но система не вылетит в ошбку об отсутствии ключа?

Если это SQL-вресия, то SQLIndex будет определять поля для SQL-индекса. Индекс будет иметь статистику...

НО: нужно не забывать про Native-версию и про размер, который прибявляет КАЖДЫЙ созданный индекс к размеу БД!

TO Arshak - см так же Navision Performace Tips. Думаю тебе это будет интересно