Владимир Бегун StalkerSПлюсы от некросплатформенности : более тесная интеграция с системой.Я не знаю как работает MS SQL Server, можно узнать как он интегрирован с MS
Windows -- например какие функциональные возможности OS он использует,
которые не использует Oracle на той же платформе? Каков выигрыш от
этого? В чём он выражается? Спасибо.Не нужно искать конкретные имена функций ядра (документированные
или нет, неважно), моё любопытство удовлетворят хотя бы основные
функциональные элементы, которые использует MS SQL Server и не
использует Oracle на Windows. В чём она эта "интеграция"? Спасибо.

StalkerS[quot Владимир Бегун]
Я не знаю как работает MS SQL Server, можно узнать как он интегрирован с MS Windows -- например какие функциональные возможности OS он использует,

StalkerSК примеру, тема этого топика. SQL-Server и операционная
система, общаясь напрямую, вырабатывают разумную стратегию использования оперативной памяти.

Я не увидел довода в пользу MS SQL Server связки Windows.

StalkerSДалее, в SQl-Server есть такое понятие как Windows Authentication. Это означает, что пользователи имеют возможность подключаться к серверу без ввода дополнительных логинов и паролей к серверу, а на основе логинов операционной системы.

Подобное существует и в Oracle.

StalkerSно и упростить администрирование. К примеру, достаточно указать серверу, что например Windows-группа "Бухгалтеры" имеет право на подключение к серверу и задать ей соответствующие привелегии в базе.

Это иногда удобно.

StalkerSИнтеграция с системным монитором. SQL-Server интегрирует туда свои счетчики, что позволяет контролировать его не только из встроенного Profiler'a, но и напрямую из системного монитора. Это удобно для комплексного анализа работы системы в целом.

Согласен, такая штука есть и для Oracle.

StalkerSАнологично, можно заставить SQL-Server Agent реагировать на оповещения операционной системы (рассылкой e-mail, запуском какой-нибудь хранимой процедуры и пр.)

В Oracle есть возможности делать тоже самое используя другие средства.

StalkerSНу и дальше в том-же духе.
"Дух" понятен. Разговор превращается в беспредметный. Спасибо.

60634.1 -- To be used as a guide for setting up basic O/S Authentication on Windows NT.
122515.1 -- Setup O/S Authentication Using Oracle Administration Assistant

Про мониторинг лень искать (я не работаю с Windows поэтому могу быть
не up to date с этими вещами).

Здесь есть кто-то, кто понимает работу ядра MS SQL Server и может
рассказать о концептуальных приемуществах использования MS SQL Server
на Windows платформе -- в ключе "интергации" database (kernel) - OS?

StalkerSМне кажется, или те вещи, которые есть в Оракл, признаются нужными и полезными, а отсутствующие - автоматически ненужными, а аргументы неубедительными ?
Довода не понял. Я спросил конкретную вещь. В ответ получил спискок
свойств предмета обсуждения. Обратным аргументом был списко свойств
(похожих) другого предмета обсуждения. Множества в той или иной мере
совпали. Да в MS SQL Server лучше сделана "интергация" инструментов
работы с MS Windows. Но я спрашивал о другом.

StalkerSНайти различия в работе ядра задача нетривиальная.
Довод принят. Поэтому я и спрашивал у тех кто знает. Чтобы не выслушивать
голословных утверждений об "интеграции".
StalkerSНо они есть, иначе как обьяснить отставание 10g от mssql на
виндовой платформе. Это видно по тестам tpc.
Это высказывание напоминает следущий диалог:

http://www.exler.ru/films/05-07-2000.htm
"
- Меня жена с тещей пытались засадить в психушку.
- За что?
- За принципы.
- Какие?
- Вон видишь суслика?
- Нет.
- И я не вижу. Но он ЕСТЬ!
"

Давай так, если тебе есть что сказать по "интеграции" database kernel -
OS -- я с удовольствием выслушаю, я готов узнать что-то новое и интересное.
Если нет... не нужно из пустого в порожнее перелевать твои собственные
"знания о предмете".

Взято из xls файлов (http://www.tpc.org/information/results_spreadsheet.asp)
Рассматривались только одинаковые (либо близкие) "железки" и OS:
TPC-CCompanySystemSpec. RevisiontpmC$/tpmCTotal Sys. CostCurrencyDatabase Software Operating System TP MonitorServer CPU Type# Server CPU'sCluster# Front EndsDate SubmittedAvailability DateUnisys Unisys ES7000 Aries 420 Enterprise Server 5.1309036.534.491384981US $ Microsoft SQL Server 2000 Enterprise Edition Microsoft Windows Server 2003 Datacenter Edition 64-bit Microsoft COM+ Intel Itanium2 1.5GHz 16N81/20/20041/30/2004Unisys Unisys ES7000 Aries 420 Enterprise Server 5.22914134.981448706US $ Oracle Database 10g Enterprise Edition Microsoft Windows Server 2003 Datacenter Edition 64-bit Microsoft COM+ Intel Itanium2 1.5GHz 16N85/11/200410/25/2004

TPC-HCompanySystemSpec. RevisionScale FactorQphHPrice Perf.($/QphH)Total Sys. CostCurrencyDatabase SoftwareOperating SystemCPU Type# CPU'sClusterDate SubmittedAvailability DateUnisys Unisys ES7000 Aries 420 Enterprise Server 2.110009853.367.93669239US $ Oracle Database 10g Enterprise Edition Microsoft Windows Server 2003 Datacenter Edition 64-bit Intel Itanium2 1500MHz 16N8/13/200411/30/2004Unisys Unisys ES7000 Aries 420 Enterprise Server 210005199.1119.12619308US $ Microsoft SQL Server 2000 Enterprise Ed. 64-bit Microsoft Windows Server 2003 Datacenter Edition 64-bit Intel Itanium2 1.5GHz 16N10/15/200310/15/2003
Мне слабо видиться возможность судить о тесной интеграции MS SQL Server
с MS Windows против Oracle на MS Windows базируясь только на результатах
этих тестов -- http://www.tpc.org/tpcc/faq.asp

StalkerS Владимир Бегун
Мне слабо видиться возможность судить о тесной интеграции MS SQL Server с MS Windows против Oracle на MS Windows базируясь только на результатах

какие-то интересные у вас доводы. Привели 2 разных теста и сделали вывод.

Я повторю свой оригинальный вопрос: "Я не знаю как работает MS SQL Server,
можно узнать как он интегрирован с MS Windows -- например какие
функциональные возможности OS он использует, которые не использует Oracle
на той же платформе?"

Я привёл результаты тестов в рамках того вопроса, который я задал. Я
не вижу никаких проблем сравнивать два продукта в одинаковых условиях
работы.

StalkerSВ свете выяснения кто как работает на виндовой платформе, как раз более логично сравнивать работу систем на одинаковых тестах. В TPC-C есть сравнение mssql и oracle на одинаковых платформах, но с разными операционными системами.

Мне неинтересно это делать. Я задал один вопрос -- ты развёл демагогию.

StalkerSВ случае "Unisys ES7000 Aries 420 Enterprise Server" Оракл стоит на Windows, и отстает по тестам от mssql на 6%, в случае "HP Integrity Superdome", оракл уже на unix'e, и опережает mssql на 22%.

Прочитай TPC FAQ, я не зря дал ссылку, прочитай и перечитай всё то что
ты написал.

StalkerSМожно-ли на основе этого сделать однозначный вывод о причинах ? Вряд-ли. Тут я с вами согласен. Зато можно сделать предположение с достаточно высокой степенью вероятности, что одна из причин этого - в платформе.

Ты не сказал ничего нового. Я спросил об этом пару дней назад, подчернув,
что мне не интересна демагогия и предположения -- ты занимаешься mssql --
объясни мне какая такая интеграция делает (не всегда, разумеется) mssql
сервер быстрее?

StalkerSА то странно получается, взаимодействие сервера с системой на примере работы с памятью вам кажется неубедительным, одинаковые тесты на разных осях тоже вам ни о чем не говорят, зато вы приводите различные тесты и делаете выводы.

Я не делаю "жестких" выводов о недостатках или приемуществах, я выясняю то
что мне интересно, я задаю вопросы.

Пример с памятью... в каких ситуациях ядро RDBMS должно отдавать память
OS? По какой причине? Почему на сервере базы данных кроме RDBMS крутиться
что-то ресурсоёмкое? Это ресурсоёмкое run-away server side process? Почему
он не ограничен в потреблении ресурсов? Кто-то считал чего стоит такое
поведение сервера если более одного процесса начинают "memory race"? Почему
это выгодно? Насколько это адаптивно? Где об этом можно, кто делал такой
анализ? Вопросов больше чем ответов. Не нужно на них отвечать здесь, я не
уверен что ты знаешь ответы -- а читать о твоих догадках мне не интересно.

ISBN: 0735609985Part II Architectural Overview
Chapter 3 SQL Server Architecture

Managing Memory

One of the major goals of SQL Server 2000 was to scale easily from a laptop
installation on Windows 98 to an SMP server running on Windows 2000 DataCenter
Server. This ability to scale requires a robust policy for managing memory. By default,
SQL Server 2000 adjusts its use of system memory to balance the needs of other
applications running on the machine and the needs of its own internal components.
These other applications can include other instances of SQL Server running on the
same machine.

When determining the optimal amount of memory to dynamically allocate to SQL
Server, the memory manager strives to keep at least 4 MB of memory completely free
and available for the operating system, but it might try to keep more available. The
amount of free space reserved for the operating system is partially determined by the
average life expectancy of a page in cache. The memory manager determines a Life
Expectancy value that indicates how many seconds, on average, a page stays in
cache if it isn't referenced at all. Performance Monitor has a counter that allows you
to view the current Life Expectancy value. That value is of course only an estimate,
and it's based on the speed at which the lazywriter checks for referenced pages and
the total amount of memory available. (I'll talk about the lazywriter later in this
section.) If the average Life Expectancy of a page is small, the memory manager tries
to keep the reserve memory at about 4 MB to increase the amount of memory
available to SQL Server. If the average Life Expectancy increases, the space reserved
for the operating system increases to up to 10 MB and the total memory for SQL
Server decreases. All instances of SQL Server on a single machine tend to work
toward the same reserve value and a similar Life Expectancy value.

As an alternative to dynamically computing the total amount of memory, you can
configure SQL Server to use a fixed amount of memory. Whether memory
allocation is fixed or dynamically adjusted, the total memory space for each instance
is considered one unified cache and is managed as a collection of various pools with
their own policies and purposes. Memory can be requested by and granted to any of
several internal components.

источник тот же

SQL Server Configuration Settings

....
min server memory and max server memory By default, SQL Server automatically
adjusts the total amount of the memory resources it will use. However, you can use
the min server memory and max server memory configuration options to take manual
control. The default setting for min server memory is 0 (MB), and the default setting
for max server memory is 2147483647. If you use the sp_configure stored
procedure to change both of these options to the same value, you basically take full
control and tell SQL Server to use a fixed memory size. This mimics the memory
configuration behavior prior to SQL Server 7. You can also use SQL Server
Enterprise Manager to set a minimum and maximum value for memory, using the
Memory tab of the SQL Server Properties dialog box (shown in Figure 17-2). To bring
up the dialog box, right-click on the name of your server and then choose
Properties.


TPC Benchmark™ C Full Disclosure Report/Unisys ES7000 Aries 420 Enterprise Server (16P)
using Microsoft SQL Server 2000 Enterprise Edition (64-bit) on
Microsoft Windows Server 2003, Datacenter Edition for 64-bit Itanium-based Systems
nameminimummaximumconfig_valuerun_valuemax server memory (MB)4 2147483647126000126000min server memory (MB)0 214748364700



TPC Benchmark™ H Full Disclosure Report/Unisys ES7000 Aries 420 Enterprise Server using
Microsoft SQL Server 2000 Enterprise Edition 64-bit on Microsoft Windows
SQL Server 2000 Enterprise Edition 64-bit Parameter Settings
nameminimummaximumconfig_valuerun_valuemax server memory (MB)4 21474836476200062000min server memory (MB)021474836476000060000

TPC-H is an ad-hoc, decision support benchmark.
Summary
The TPC Benchmark™H (TPC-H) is a decision support benchmark. It consists of a
suite of business oriented ad-hoc queries and concurrent data modifications. The
queries and the data populating the database have been chosen to have broad
industry-wide relevance. This benchmark illustrates decision support systems that
examine large volumes of data, execute queries with a high degree of complexity, and
give answers to critical business questions.

The performance metric reported by TPC-H is called the TPC-H Composite
Query-per-Hour Performance Metric (QphH@Size), and reflects multiple aspects of
the capability of the system to process queries. These aspects include the selected
database size against which the queries are executed, the query processing power
when queries are submitted by a single stream, and the query throughput when
queries are submitted by multiple concurrent users. The TPC-H Price/Performance
metric is expressed as $/QphH@Size.

Владимир Бегунмоё любопытство удовлетворят хотя бы основные функциональные элементы,
которые использует MS SQL Server и не использует Oracle на Windows. В чём
она эта "интеграция" Каков выигрыш от этого? В чём он выражается?

Отвечаю сам себе:

- интергация -- активная работа с OS. Моё подозрение -- подход может быть неээфективным при пиковых нагрузках
- выигрыш - неопределён, зависит от использования прочих приложений
- выражается в to scale easily from a laptop installation on Windows 98 to
an SMP server running on Windows 2000 DataCenter Server.

Я думаю что "светлая цель" иметь на сервере другие приложения, которые
имеют требования к потреблению памяти, заставляющие ядро базы отдавать
её обратно может вызвать справедливаое недоуменее. Думаю не только у
меня одного.

ISBN: 0735609985./The SQL Server Kernel and Interaction with the Operating System

The SQL Server kernel is responsible for interacting with the operating system. It's a
bit of a simplification to suggest that SQL Server has one module for all operating
system calls, but for ease of understanding, you can think of it in this way. All
requests to operating system services are made via the Win32 API and C run-time
libraries. When SQL Server runs on Windows NT/2000, it runs entirely in the Win32
protected subsystem. Absolutely no calls are made in Windows NT/2000 Privileged
Mode; the calls are made in User Mode. This means that SQL Server cannot crash the
entire system, it cannot crash another process running in User Mode, and other such
processes cannot crash SQL Server. SQL Server has no device driver-level calls, nor
does it use any undocumented calls to the operating system. If the entire system
crashes (giving you the so-called "Blue Screen of Death") and SQL Server happens to
have been running there, one thing is certain: SQL Server did not crash the system.
Such a crash must be the result of faulty or incompatible hardware, a buggy device
driver operating in Privileged Mode, or a critical bug in the Windows NT/2000 operating
system code (which is doubtful).

Competitors have occasionally, and falsely, claimed that SQL Server must have
special, secret hooks into the operating system. Such claims are likely the result of
SQL Server's astonishing level of performance. Yes, it is tightly integrated with the
operating systems on which it runs. But this integration is accomplished via
completely public interfaces—there are no secret "hooks" into the operating system.
Yes, the product is optimized for Windows NT/2000. That's SQL Server's primary
platform. But other products could also achieve this level of optimization and
integration if they made it a chief design goal. Instead, they tend to abstract away
the differences between operating systems. Of course, there's nothing wrong with
that. If Microsoft had to make sure that SQL Server could run on 44 different
operating systems, it might also take a lowest-common-denominator approach to
engineering. To do anything else would be almost impossible. So although such an
approach is quite rational, it is in direct conflict with the goal of fully exploiting all
services of a specific operating system. Since SQL Server runs exclusively on
Microsoft operating systems, it intentionally uses every service in the smartest way
possible.

A key design goal of both SQL Server and Windows NT is scalability. The same binary
executable files that run on notebook computer systems run on symmetric
multiprocessor super servers with loads of processors. Windows NT/2000 is an ideal
platform for a database server because it provides a fully protected, secure, 32-bit
environment. The foundations of a great database server platform are preemptive
scheduling, virtual paged memory management, symmetric multiprocessing, and
asynchronous I/O. The operating system provides these, and SQL Server uses them
fully. The SQL Server engine runs as a single process on Windows NT/2000. Within
that process are multiple threads of execution. The operating system schedules each
thread to the next processor available to run one.

Да, речь везде и у всех о всё том же scalability... делимся ресурсами активно
общаясь с OS -- это тоже решение, лучше оно или хуже можно выяснить только
действительно запуская несколько MS SQL Server instances на одной машине
меняя workload можно ещё и в игрушки поиграть...

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

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ar_sa_40vt.asp

http://blogs.msdn.com/slavao/archive/category/9005.aspx -- очень хорошая подборка.

External Memory pressure: RM and Buffer Pool

From SQLOS perspective Buffer Pool is a single page allocator - extensively used
memory manager. External memory pressure is signaled by Windows. RM wakes up
and broadcasts corresponding notification to clerks. Upon receiving the notification BP
recalculates its target commit, amount of physical memory BP is allowed to consume.
Keep in mind that target commit can't be lower than configuration parameter
specified through sp_configure min server memory and can't be higher of max server
memory. If new target commit is lower than currently committed buffers, BP starts
shrinking until external physical memory pressure disappears. During this process BP
tries to decommit or in case of AWE free physical memory back to OS. Remember
that in SQL2000 BP didn't react to physical memory pressure when running in AWE mode.

Вот интересное замечание:
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=37890
Enabling AWE has no effect if your server has less than 4GB of RAM. By default,
Windows is limited to 4GB of physical memory. However, by leveraging Physical
Address Extensions (PAE), Win2K AS can support 8GB of memory, and Windows
Datacenter Server can support 64GB. You invoke PAE by including the /PAE switch in
the boot.ini file. However, each 32-bit process usually has access to only 2GB of
address space. To let processes allocate more physical memory than can be
addressed by the 2GB of address space, Microsoft created AWE. These extensions
permit the allocation and use of up to the amount of physical memory the OS
supports.

Most people use AWE in conjunction with the /PAE switch to let SQL Server take
advantage of physical memory greater than 4GB. Using AWE without /PAE lets SQL
Server access as much as 4GB of physical memory. With AWE enabled, SQL Server by
default allocates almost all memory during startup , leaving 256MB or less free. This
memory is locked and can't be paged out. Consuming all available memory can prevent
other applications or SQL Server instances from starting. I strongly recommend that
you use the max server memory option with AWE enabled to ensure that some
memory exists for other SQL Server applications or instances.
Т.е. деталек не меньше, чем при настройке работы Oracle.