Экспресс SQL Server 2008 R2 и VMware
Как насчет того, чтобы использовать представления информационной схемы или базовые системные таблицы как sysobjects, syscolumns и затем использовать оператор FOR XML для выкладывания некоторого xml. Вот что-то для запущения Вас:
SELECT o.name as table_name
,c.name as column_name
,t.name as column_type
,t.length as column_length from sysobjects o
inner join syscolumns c on o.id=c.id
inner join systypes t on c.xtype=t.xtype
where o.xtype='u'
FOR XML RAW
Вполне возможно, что наблюдаемая вами «огромная служба vmware» связана с раздутием памяти , которое может произойти в случае нехватки физической памяти на вашем хосте ESX. Наблюдаемые периоды полной загрузки системы, в то время как она ничего не делает, в свою очередь, вероятно, представляют собой время ожидания ввода-вывода подкачки на стороне хоста ESX. Пока ESX меняет местами страницы (опять же, из-за нехватки памяти), это останавливает гостя, оставляя, таким образом, лишь несколько циклов для фактической обработки.
Уровень гипервизора для доступа к диску не вызовет такой большой проблемы. . Что делает виртуальная машина на сервере? Похоже, что это, вероятно, раздувает память и борется за оперативную память или процессор с другими ресурсами на вашем сервере VMware. Какую версию VMware вы используете? Насколько чрезмерно загружены ваша память и ресурсы процессора? У меня около 400 виртуальных машин с SQL-серверами, и они не испытывают проблем. Но я не слишком много занимаюсь оперативной памятью.
Это неудивительно. По многим традиционным меркам операционная система базы данных в этом случае является гостевой операционной системой, работающей поверх Windows. Когда он запускается, он немедленно захватывает кусок ОЗУ и кусок диска, которым SQL-сервер хочет управлять самостоятельно по соображениям производительности. Как только вы попросите хост стать гостем в VMWARE, вы вводите еще один уровень арбитража в доступе к диску и памяти, связанный с производительностью SQL Server. Еще одна особенность гостевых операционных систем заключается в том, что они имеют свой собственный естественный уровень консолидации для поддержания производительности. В случае SQL Server, хотя и не обязательно SQL Express, вы можете объединить несколько экземпляров базы данных на одном аппаратном обеспечении, тем самым поддерживая производительность и доступ к ресурсам для механизма базы данных и в то же время сокращая многие статьи затрат, которые стимулируют виртуализацию со стороны высшего руководства.
С вашим примечанием, что производительность ухудшается по мере того, как добавляется все больше и больше данных, это будет означать, что у вас будет все больше доступа к диску для извлечения информации. Каждый из этих запросов должен быть обработан гипервизором до того, как он фактически попадет на диск, и чем больше доступ к диску, тем больше совокупный ущерб от всех этих микросекунд на задержку арбитража. Лучшее, что вы можете сделать в этом случае, - это изучить свои запросы. Убедитесь, что они сверхэффективны в производстве, что они используют индексы, когда и где это возможно, чтобы минимизировать активность сканирования таблиц (что обычно имеет место, когда время ответа напрямую связано с размером таблицы данных). Чем меньше запросов вы должны сделать к дисковой подсистеме, тем меньше возможностей будет у гипервизора для арбитража запросов и тем быстрее станет ваша система.
Если ваши данные растут довольно хорошо, вам нужно будет посмотреть на другие возможности двигаться вперед, поскольку у вас, скорее всего, закончится газ из-за способности SQL Express обрабатывать все большие и большие наборы данных раньше, чем позже ... и обычно это происходит в неудобное время, когда вам нужно вытащить вещи за дверь. Я думаю, что ограничение на SQL Express 2088 R2 составляет 10 ГБ. Это не незначительный объем данных, но тот, который, кажется, легко превзойти в наши дни.
Чем меньше запросов вы должны сделать к дисковой подсистеме, тем меньше возможностей будет у гипервизора для арбитража запросов и тем быстрее станет ваша система.Если ваши данные растут довольно хорошо, вам нужно будет посмотреть на другие возможности двигаться вперед, поскольку у вас, скорее всего, закончится газ из-за способности SQL Express обрабатывать все большие и большие наборы данных раньше, чем позже ... и обычно это происходит в неудобное время, когда вам нужно вытащить вещи за дверь. Я думаю, что ограничение на SQL Express 2088 R2 составляет 10 ГБ. Это не незначительный объем данных, но тот, который, кажется, легко превзойти в наши дни.
Чем меньше запросов вы должны сделать к дисковой подсистеме, тем меньше возможностей будет у гипервизора для арбитража запросов и тем быстрее станет ваша система.Если ваши данные растут довольно хорошо, вам нужно будет посмотреть на другие возможности двигаться вперед, поскольку у вас, скорее всего, закончится газ из-за способности SQL Express обрабатывать все большие и большие наборы данных раньше, чем позже ... и обычно это происходит в неудобное время, когда вам нужно вытащить вещи за дверь. Я думаю, что ограничение на SQL Express 2088 R2 составляет 10 ГБ. Это не незначительный объем данных, но тот, который, кажется, легко превзойти в наши дни.
Если ваши данные растут довольно быстрыми темпами, вам следует рассмотреть другие варианты в дальнейшем, поскольку у вас, скорее всего, закончится топливо из-за способности SQL Express обрабатывать все большие и большие наборы данных раньше, чем позже. ... и обычно это происходит в неудобное время, когда вам нужно вынести вещи за дверь. Я думаю, что ограничение на SQL Express 2088 R2 составляет 10 ГБ. Это не незначительный объем данных, но тот, который, кажется, легко превзойти в наши дни.
Если ваши данные растут довольно быстрыми темпами, вам следует рассмотреть другие варианты в дальнейшем, поскольку у вас, скорее всего, закончится топливо из-за способности SQL Express обрабатывать все большие и большие наборы данных раньше, чем позже. ... и обычно это происходит в неудобное время, когда вам нужно вынести вещи за дверь. Я думаю, что ограничение на SQL Express 2088 R2 составляет 10 ГБ. Это не незначительный объем данных, но тот, который, кажется, легко превзойти в наши дни.
Итак, vmWare не должно было использовать 1G3 - существует документированная утечка памяти из-за какого-то реентерабельного IP. Перезагрузка машины (в случае сомнений выключите ее и снова включите) устранила это. С другой стороны, SQL Express не должен занимать 3 ГБ. Согласно MS, это должен быть предел в 1 ГБ. Память SQL Express была (вручную) привязана к 786 МБ - мало? увеличение или уменьшение 256M казалось хуже, но изменения не были кардинальными, поэтому мы выбрали медианное значение. vmWare медленно увеличивается - до 89 МБ - началось с 10 МБ. Обратите внимание, что с SQL 2008 вы можете изменить объем памяти без перезапуска службы (SQL).