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

С фрагментацией бороться стоит видимо путём задания параметров роста датафайлов (чтоб не по "чайной ложке" расширялся, а сразу на неделю, а то и месяц работы хватало), или просто заранее задать размер файла достаточный для обозримого объёма данных (на год например). То как "внутри" сервер блоки выделяет под таблицы/индексы - это уже сугубо внутренние его алгоритмы, и по идее это тоже настраивается (я с MS SQL чуть более чем совсем никак но в оракле есть масса разных алгоритмов/способов управления этими нюансами - думаю в MS есть хоть что-то похожее). А кэширование - опять же в оракле есть 3 раздельно настраиваемых (по необходимости) "пула" (по сути это куски кэш-памяти блоков) - это позволяет "развести" разные таблицы так, чтобы обращения к одним не вытесняли из кэша блоки других. Ну грубо говоря при одном "общем" кэше на 200Мб ты читаешь пару справочников по 1 Мб каждую минуту - их блоки сидят в кэше, всё хорошо, всё быстро - НО каждые 10 минут ты ещё читаешь 200Мб таблицу и она забивает весь кэш вытесняя оттуда эти "часто нужные" блоки. Ещё хуже, если раз в час ты читаешь некоторую другую 1Гб таблицу - она и блоки этой 200Мб-ной таблицы вытеснит, и их придётся потом заново читать с диска
В принципе это всё слишком прямолинейно - обычно сервера сами берут на себя заботу обо всём этом, и "алгоритмы вытеснения" куда как более продвинутые используются, но иногда допустимо и "ручное управление" - хотя это требует глубоких знаний и весьма тщательного анализа - что, кому и для чего требуется.

расчтывать размеры файлов для 1це у мну уже вчерашний день
опытным путем расчитал что база 1це сиквела в десять раз больше аналогичной файловой
таким образом мона заранее увеличить размер до нужного и потом уже заливать данные
я обычно так делаю когда нужно создать базу 1це из выгрузки, работает на порядок быстрее, ну оно и коню понятно
пишу "коню" и думаю: сферическому?
а вот на счет кеширования в боле маловато информации по его настройке, хотя кажись еще пара книжек гдето завалялось
пора откапывать

Foxtrot
расчтывать размеры файлов для 1це у мну уже вчерашний день опытным путем расчитал что база 1це сиквела в десять раз больше аналогичной файловой
таким образом мона заранее увеличить размер до нужного и потом уже заливать данные
я обычно так делаю когда нужно создать базу 1це из выгрузки, работает на порядок быстрее, ну оно и коню понятно
пишу "коню" и думаю: сферическому?
а вот на счет кеширования в боле маловато информации по его настройке, хотя кажись еще пара книжек гдето завалялось
пора откапывать

Канат, оставь кэширование в покое. Сервер все сам себе закэширует если это действительно нужно будет. Не пытайся быть серверее сервера. У тебя все равно нет всей имеющейся у него информации, требующейся для првильного распределения ресурсов. Ищи узкие места.

уговорили, авторитетные вы мои
перевел Recovery model в Simple и успокоился
остальное пусть останется на совести сервака

Сиквел 2005 и выше очень эффективно кэширует однотипные запросы.

спс, буду знать
но у мну 2000, так сказать шо админ прописал
хотя наверное мона попросить установить нелицензируемый вариант

Foxtrot
но у мну 2000, так сказать шо админ прописал
хотя наверное мона попросить установить нелицензируемый вариант

Тяжелый случай. Переползай по мере возможности хотя бы на 2005.

как появица возможность, обязательно перейду
не думаю, что сиквелы последних версий различаются меж собой как небо и земля
по мне так все самое интересное началось как раз с 2000-й версии, но это уже канешно субъективно





Исправлено 1 раз(а). Последнее : Foxtrot, 18.03.11 21:16

ssa

Foxtrot
но у мну 2000, так сказать шо админ прописал
хотя наверное мона попросить установить нелицензируемый вариант

Тяжелый случай. Переползай по мере возможности хотя бы на 2005.

В чём ущербность 2000-ого на твой взгляд?

PaulWist

ssa

Foxtrot
но у мну 2000, так сказать шо админ прописал
хотя наверное мона попросить установить нелицензируемый вариант

Тяжелый случай. Переползай по мере возможности хотя бы на 2005.

В чём ущербность 2000-ого на твой взгляд?

В нем труднее проводить оптимизацию.

ssa
В нем труднее проводить оптимизацию.

Переведи,... что значит труднее, из-за чего т(из-за отсутствия соответствующих тулзов или же из-за того, что эти тулзы неправильно работают)?

PaulWist

ssa
В нем труднее проводить оптимизацию.

Переведи,... что значит труднее, из-за чего т(из-за отсутствия соответствующих тулзов или же из-за того, что эти тулзы неправильно работают)?

И отсутствие тулзов, и неправильность, и отсутсвие Include у индексов...

ssa
И отсутствие тулзов, и неправильность, и отсутсвие Include у индексов...

Если про тулзы худо-бедно можно согласиться, то про Include ты "загнул", его отсутствие не есть "ущербность" просто by design его не было, это всё равно, что пенять на "Жигули", что в них нет кондиционера

Так Include нужен для работы нового ядра и системы кэширования данных, как я понимаю. Если 2000-й имел компактные индексы и не требовал включения, то 2005 имеет индексы размером с таблицу и просто дублирует данные. По-моему, это плохо.

В принципе MS снимает с себя ответственность говоря:

Цитата:

Avoid adding unnecessary columns. Adding too many index columns, key or nonkey, can have the following performance implications:
Fewer index rows will fit on a page. This could create I/O increases and reduced cache efficiency.

More disk space will be required to store the index. In particular, adding varchar(max), nvarchar(max), varbinary(max), or xml data types as nonkey index columns may significantly increase disk space requirements. This is because the column values are copied into the index leaf level. Therefore, they reside in both the index and the base table.

Index maintenance may increase the time that it takes to perform modifications, inserts, updates, or deletes, to the underlying table or indexed view.

You will have to determine whether the gains in query performance outweigh the affect to performance during data modification and in additional disk space requirements. For more information about evaluating query performance.

типа мы Вам дали инструмент, а уж как его эффективно использовать зависит от разработчика.

В текущем MS SQL нет индексно-организованных таблиц? Ну т.е. когда все "неключевые" поля включаются в индекс, и сама "базовая таблица" вообще не создаётся.

такие фишки в 1це не канают, потому как нельзя менять структуру базы
помница пытался вручную добавить индекс, так при загрузке конфигуратор мне высветил окно предупреждения и работать отказался
а добавить индекс через конфигуратор=морду1це у той таблицы нет возможности

Foxtrot
такие фишки в 1це не канают, потому как нельзя менять структуру базы
помница пытался вручную добавить индекс, так при загрузке конфигуратор мне высветил окно предупреждения и работать отказался
а добавить индекс через конфигуратор=морду1це у той таблицы нет возможности

А у меня сейчас навешана куча индексов и не ругается. На 8.1 и MS SQL 2005
Может я что не так делаю?

Игорь, такого нет, но есть так называемый кластерный индекс, т.е. физически упорядоченные в пределах страницы данные, отсортированные по столбцам индекса. Но это не новшество.

Проблема в том, что если не включить столбцы в индекс выражением Include (не строить индекс по ним, а просто добавить в выходные данные, которые хранятся в индексном файле!), то оптимизатор откажется использовать этот индекс.

Например, требуется выполнить запрос:
select f1, f2 from tbl1 where f3=5

Так вот,
create index idx1 on (f3)
не будет использован оптимизатором.
Потребуется
create index idx1 on (f3) include (f1,f2).
Т.е. результирующие столбцы добавить в индекс.
Соответственно, индекс увеличится на размер столбцов и будет обновляться при обновлении таблицы.





Исправлено 1 раз(а). Последнее : Влад Колосов, 21.03.11 18:46