Re: Из .Net XML в SQL2000 datetime - Чаты на GotDotNet [GDN]

В свое время я прочел книгу Рона Саукапа "Основы SQL Server 6.5". В данной книге очень хорошо описана работа ядра SQL Server. Каким усовершенствованиям подверглось ядро с тех времен. Особо интересует Yukon. А так же можно ли ожидать в обозримом будующем труда, подобного книге Рона Саукапа, написанного кем нибудь из SQL Server Team, но описывающего более позние модели SQL Server.

Спасибо.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Общие вопросы:
1) Cколько человек разрабатывает Sql Server Yukon? Насколько это сплоченная команда? Занимаются ли разработчики чем-то еще помимо работы с данными?
2) Кто на данный момент занимается идеологом группы разработки?
3) Как известно, проект Yukon подходит к концу. Каковы в общих чертах ваши планы на будущее. Планируется ли уже сейчас Yukon 2?
4) Принимает ли ваша группа неофициальные рекомендации/предложения/сумашедшие идеи по вопросам построения серверов БД?

У меня также ОГРОМНАЯ куча общеспециальных вопросов и специальных вопросов, которые я выложу завтра.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Общеспециальные вопросы:
1) В пресс-релизах MS, посвященных Yukon очень часто можно встретить фразы "способость служить хостом CLR", "управляемый код выполняется в среде CLR, хостом для которой служит ядро баз данных" и т.п. Как на самом деле ядро взаимодействует с CLR? Можете привести хотя бы примеры простых функций подобного внутреннего взаимодействия или пояснить это на пальцах?
2) Может ли разработчик под Yukon полностью отказаться от T-SQL в пользу управляемого кода? Означает ли такая мощная поддержка языков платформы в Yukon скорую гибель стандарта SQL в серверах БД MS?
3) Идея управляемых хранимых процедур (как впрочем и всего управляемого кода

), по моему мнению, является одним из наиболее ценных практических приложений использования управляемого кода вообще. Но существуют ли какие-либо грабли в этом вопросе? Когда следует использовать T-SQL вообще? И стоит ли, если разработчик готов мириться с небольшими потерями производительности?
4) Прочно ли войдет XML Query в сервера БД MS или в будущем нас ожидают другие подмножества и диалекты XML? А может это просто "однодневка" Yukon?

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Аноним, Вы писали:

А>2) Может ли разработчик под Yukon полностью отказаться от T-SQL в пользу управляемого кода? Означает ли такая мощная поддержка языков платформы в Yukon скорую гибель стандарта SQL в серверах БД MS?
А>3) Идея управляемых хранимых процедур (как впрочем и всего управляемого кода

), по моему мнению, является одним из наиболее ценных практических приложений использования управляемого кода вообще. Но существуют ли какие-либо грабли в этом вопросе? Когда следует использовать T-SQL вообще? И стоит ли, если разработчик готов мириться с небольшими потерями производительности?
Эти вопросы были довольно хорошо освещены еще со времен выхода PDC'шной версии, вплоть до сравнения производительности T-SQL и CLR для разных задачь и рекомендаций где что использовать. Сейчас сходу все не нашел, но в частности здесь:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/sql_ovyukondev.asp

Изданы также Inside SQL Server 7.0 (авторы Soukup, Delaney) и Inside SQL Server 2000 (книги нет под рукой, так что не помню авторов. Delaney + может быть еще кто-то).
Довольно трудно говорить каким усовершенствованиям подверглось ядро по сравнению с 6.5, поскольку оно было очень и очень существенно переписано в 7.0. Могу порекомендовать книгу в которой я принимал участие — SQL Server 7.0 для профессионалов. Там есть материал по различиям 6.5 и 7.0.
Книга по Yukon наверняка будет. Надо только дождаться самого Yukon'а.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Sql Server Service Broker.
Идеи подобные этой просто "витают в воздухе" с момента бума электронной коммерции в Интернете. А с появлением новых средств удаленного взаимодействия, подобные задачи и впрямь выходят на первый план.
В связи с этим такой вопрос. Основа технологии по моему мнению очень напоминает MSMQ. Означает ли это, что далее подобные технологии в работе с данными будут изолированы от таких технологий как COM+ или Remoting? Каковы реальные преимущества SSSB перед COM+ и Remoting? Возможен ли полный отказ от COM+ и Remoting в данном контексте?
Извините, если сумбурно

, я сам так сказать только разбираюсь.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Попытюсь отвечать на вопросы Александра по порядку.
Перед началом отмечу, что ответ на большинство вопросов составит неплохую книгу или по крайней мере объемистую статью.
1. По моим представлениям непосредственно SQL Server разрабатывают порядка 450 человек. (Надеюсь, вы не ожидаете от меня досконального знания всего, что они делают.)
2. Трудно назвать имя "главного" идеолога. Есть группа архитекторов, и, вообще, это коллективный труд.
3. Будущие версии естественно планируются. (В противном случае мы просто должны разойтись после выпуска Yukon

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

>4.

Готовьтесь — я теперь просто завалю вас спамом

. Всю свою сознательную жизнь работал с серверами БД, вот теперь очень хочется выплеснуть все накопленное

.
>Эти вопросы были довольно хорошо освещены еще со времен >выхода PDC'шной версии, вплоть до сравнения >производительности T-SQL и CLR для разных задачь и >рекомендаций где что использовать
Безусловно, я отлично помню PDC. Эрик Браун тогда написал, что главная рекомендация — это постоянное тестирование Sql Server Profiler для оценки производительности приложения, а потом делать выбор, исходя из результатов тестирования. Меня, конечно, интересует вторая часть вопроса.
И стоит ли, если разработчик готов мириться с небольшими потерями производительности?

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Пара практических вопросов по непосредственной работе сервисов SQL Server 2000:
1) Ошибка "Cannot generate SSPI context" возникает практически каждый раз при изменении аккаунта сервиса SQL Server. Причем многочисленные рецепты, приводимые MS фактически не часто срабатывают (про рецепты http://support.microsoft.com/default.aspx?scid=kb;en-us;883714). Меня, как разработчика интересует вопрос — исправлено ли это в Yukon?
2) Sql Server Agent. "BUG: Starting the SQL Server Agent is Unsuccessful on a Backup Domain Controller". Это также будет исправлено?

Общий вопрос. Насколько процентов обновился Yukon? Можно ли твердо сказать, что все старые проблемы присущие SQL Server 2000 действительно в прошлом и мы можем работать только с новыми проблемами

(уверен, что они, естественно, будут)?

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Вот вопос немного технический, если позволите...

Разбираясь на досуге с беттами Юкона, заметил такую особенность.
Если раньше оптимизатор, при выборке данных и наличии подходящего под условие, но не покрывающего индекса выбирал Bookmark Lookup, то теперь он выбирает сканирование кластерного индекса, даже в очень простых случаях.
Например, в этом запросе (по базе Northwind):

SELECT * FROM  Customers WHERE City = 'Sao Paulo'

Юкон выберет сканирование кластерного индекса, хотя по City индекс есть, и 2000 выберет index seek + bookmark lookup.
Если сравнить стоимость планов, то план предлагаемый Юконом значительно выгоднее, но тут есть одна тонкость, сканирование индекса — это перебор всех ключей, а не просто проход по дереву до нужных, а значит это лишние блокировки при чтении и, как следствие большая вероятность помешать другим запросам даже послужить причиной дедлока.
Насколько я заметил Юкон вообще стараетсяи збежать бкмарков всеми возможными способами и тут же сваливается в сканирование... При этом в большинстве случаев его план оказывается выгоднее, но иногда его план все же хуже, хоть и не на много...

Почему Юкон поступает именно так?
Это рассчет на то, что базы в основном будут функционировать в Snapshot режиме? Но тут все равно могут быть поблемы, особенно для пишущих запросов, ведь Юкон, насколько я разобрался, не использует предварительных версионных сканов, как это делают обычные версионники при записи... Да и разумнее наверное было бы в таком случае перед построением плана определять в каком режиме работает база и для баз без поддержки Snapshot'а работать по старинке, хоте это, возможно, и не так просто..

Или же база Northwind достаточно маленькая, и изменения в механизме хранения (а они безусловно были, хотя бы из за того же snapshot'а) достаточны для того, чтобы данные по страницам легли немного по другому, чего хватило оптимизатору чтобы выбрать другой план?
Или же вообще пока на планы смотреть рано и идет просто обкатка нового оптимизатора?

Короткий ответ про оптимизатор.
Отвечаю из общих соображений. Не имеет особого смысла смотреть на планы, когда в таблице 3 страницы. Любой план будет хорош. Table Scan близок к идеалу.
Вообще говоря, количество возможных планов/стратегий настолько велико, что имеет место проблема "не займет ли выработка оптимального плана больше времени, чем отработка неоптимального плана, но сразу".
К сожалению, не могу сказать в каком порядке оптимизатор перебирает планы и от чего это зависит (алгоритмы там не простые). Однако общее правило действует — если найден достаточно хороший план, то дальше искать в общем случае не оправдывается. Естественно, критерий "достаточной хорошести" зависит от статистики. Такой вот обще-теоретический ответ. Очень трудно судить о работе оптимизатора манипулируя крошечные таблицы.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Аноним, Вы писали:

А> Однако общее правило действует — если найден достаточно хороший план, то дальше искать в общем случае не оправдывается.
<...>
А> Очень трудно судить о работе оптимизатора манипулируя крошечные таблицы.
Спасибо, конечно я знаю, что перебирать все возможные планы в поисках самого оптимального смысла не имеет, перебор обойдется дороже, и современные оптимизаторы выдают не самый оптимальный план, а так называемый "квази оптимальный", который просто достаточно хорош...
Но я экспериментировал и с достаточно большими таблицами (просто стандартная база наглядный пример) и поведение примерно то же самое, Юкон гораздо больше боится bookmark lookup's чем предыдущая версия, вот и было любопытно, почему...

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

Кратко, суть в следующем, System.Xml.Serialization.XmlSerializer преобразует System.DateTime в следующую сторку

2004-09-17T12:08:57.0000000+04:00

функция convert sql сервера с флагом 126 ожидает немного другую сторку, а именно

2004-09-17T12:08:57.000

т.е. несоответсвие заключается в точности ms, а также в дополнительной информации о часовом поясе.

В итоге приходиться делать так

convert(datetime, left(startTime,23), 126)

Вопрос: Будет ли какое-то исправление, дополнение к MSSQL 2000 Server, MSDE 2000, дабы обеспечить поддержу .Net Framework?

Уважаемые коллеги
Я, признаюсь, несколько подавлен объемом и глубиной вопросов. На некоторые вопросы и в правду нужно отвечать статьей. Я попробую рекрутировать соратников. Надеюсь вы сможете читать ответы по-английски, если что.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

(Sorry for using English, but It is much more convenient and less time consuming for me at this point, please let me know if it is ok)

Quickly about myself: I am here to help Gregory to answer your questions.
I have been working on SQL Server team for 4.5 years (for 7 at Microsoft). My major responsibility include: Memory management, Scheduling and other OS services.
3, 4: Yep we are already thinking about Yukon+. Currently we are brainstorming in different directions. Your input is very valuable and we will seriously take it into consideration. Feel free to shoot your crazy ideas at us

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

1) В пресс-релизах MS, посвященных Yukon очень часто можно встретить фразы "способость служить хостом CLR", "управляемый код выполняется в среде CLR, хостом для которой служит ядро баз данных" и т.п. Как на самом деле ядро взаимодействует с CLR? Можете привести хотя бы примеры простых функций подобного внутреннего взаимодействия или пояснить это на пальцах?
We are working very closely with CLR team to provide the best possible integration between SQL Server and CLR engine. Both components are tightly integrated. CLR leverages SQL Server memory management, thread scheduling, synchronization primitives and other OS services. SQL Server scheduling utilizes non preemptive scheduling without tight integration it will be possible for CLR engine to take over server’s schedulers and starve other requests. Moreover both engines, server and CLR, are very memory hungry. We had to come with ways for both of them to coexist in the same address space. So the integrations between CLR and Sever are much tighter and smoother as compare to COM for example. You can see the integration in action by executing select * from sys.dm_os_memory_clerks. There you might see clerks/caches for CLR, if you actually use them ?. In addition to CLR we also provided tighter integration with MDAC, SNAC. Now it leverages SQL Server OS services the same as CLR Engine.
2) Может ли разработчик под Yukon полностью отказаться от T-SQL в пользу управляемого кода? Означает ли такая мощная поддержка языков платформы в Yukon скорую гибель стандарта SQL в серверах БД MS?
I don’t think so. T-SQL and CLR will coexist happily for long time. However CLR will take over some things that are really painful to perform in T-SQL. Both of the technologies have their space under the sun, so I wouldn’t blindly jump on rewriting all T-SQL code in CLR

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Thanks for answers, Stanislav. You will not complicate to answer, if I shall ask questions in English?
>Feel free to shoot your crazy ideas at us
I shall not keep you waiting

Уважаемые, коллеги, я заранее прошу прощения за свой косноязычный английский. Если что, сразу поправляйте меня.

Григорий, вопросы лучше задавать на русском?

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Alexander Lozhechkin [MSFT], Вы писали:

День добрый.

Вопрос праздный: кто занимается разработкой ADO .NET? Команда SQL Server или разработчики фреймвока?

Вопрос насущный: с более ранними версиями ADO работать мне не довелось, поэтому сравнивать не могу. Однако, отсоединенная модель работы ADO .NET в некоторых случаях очень неудобна.
Задавал вопросы в форуме RSDN, однако ответа так и не получил.
Проблема заключается в следующем. Имеется таблица, реализующая справочник товаров, содержащая 50 — 300 тыс. записей.
Пользователь хочет открыть справочник и, грубо говоря, протащить бегунок таблицы сверху до низу — прокрутить всесь справочник.
Загружать копию справочника в датасет — долго и дорого по ресурсам.
Что-то типа реализации курсоров в ADO .NET я не нашел, как и какого-либо аналога.
Использовать более компактные выборки данных я тоже не могу, т.к. необходим быстрый поиск — пользователь начинает вводить название товара, курсор в датагриде позиционируется на нужную запись по мере ввода названия.
Обосновать невозможность подобной вещи я тоже не могу — в MS Access та же самая таблица открывается мгновенно и готова к использованию

Как такая задача может быть решена в связке SQL Server + .NET? Если может быть решена...
Заранее благодарен.

... << RSDN@Home 1.1.3 stable >>

	От:	Аноним
	Дата:	09.09.04 08:48
	Оценка:
	#Имя:	-=???=-

	От:	Аноним
	Дата:	10.09.04 07:20
	Оценка:
	#Имя:	-=???=-

	От:	Аноним
	Дата:	10.09.04 13:20
	Оценка:
	#Имя:	-=???=-

	От:	Аноним
	Дата:	13.09.04 06:00
	Оценка:
	#Имя:	-=???=-

От:	Merle	http://rsdn.ru
Дата:	13.09.04 09:03
Оценка:	1 (1)

От:	Муравей	http://www.livejournal.com/users/podovan/
Дата:	17.09.04 11:06
Оценка: