Встреча в Microsoft France по поводу Yukon

[Dmitry67]

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

Встреча мне очень понравилась. Это были не marketing guys, как мы боялись а специалисты которые учавствуют в разработке. Вот мои некоторые наблюдения, то что запонилось

-----
То что Yukon делает с XML это круто. Честно говоря я раньше недооценивал эти возможности. Особенно мне понравились индексы по XML. В свое время в Oracle были сделаны Object oriented extensions, когда можно было таблицы хранить в полях итд. Было крайне неудобно, и поиск по вложенным документам был возможен только через master.

То что сделали в Yukon - это полностью покрывает эту функциональность (то есть detailed вы можете хранить в поле XML, и более того, искать по этим полям). Я упомянул об Oracle. оказалось, что один из них в свое время как раз этим самым в Oracle и занимался

Меня беспокоил вопрос о CLR. Отрадно, что память используемая CLR та же, что и SQL server, то есть memory intensive CLRs не будут вытеснять sqlsrvr.exe. Правда, вопрос что будет, если SQL server использует AWE (очевидно CLR не могут использовать AWE) остался без ответа

Я наконец услышал - слава Богу - то о чем сам долго говорил. CLR не пишутся для того чтобы их использовали ВМЕСТО SQL. Переводите текст, превращайте .JPG в GIF в CLR, но не надо переписывать insert ... select на C#. Хорошо что в Microsoft это четко понимают. К сожалению слишком много энтузиазма среди девелоперов - типа вот больше не придется писать на этом ugly TSQL !

Если девелоперы слишком оптимистичны по отношению к CLR, то админы (и я) наоборот. И у Microsoft уже было предусмотрено много чтобы успокоить админов. Обещаны богатые средства статистики, прифилирования SQL profiler итд для CLR

Тем не менее ряд вопросов до конца я не понял. Я спросил нет ли проблем с убиванием коннекций который выполняют CLR по kill или в результате deadlock. Они стали спорить между собой, из обрывков разговоря я понял что хотя в презентации Power Point написано что все OK, но в результате порчи каких то shared state все может быть совсем плохо. Кроме того, сервер пытается сам убить 'runaway CLRs', но что такое runaway ? Не до конца понятно как ненароком не убить просто долго считающий процесс

Я упомянул про то что неплохо бы поиметь приоритеты процессов и чтобы один table scan для reporting не вышибал напрочь кеш из под OLTP. Они переглянулись и засмеялись: оказывается, я не первый и не сотый кто просит о том же

Вопрос про то что зачем на dedicated server for SQL server система NT подрезает память серверу если он не активен (weekend), в итоге к понедельнику он становится совсем маленький и IIS дает кучу таймаутов остался в общем без ответа. Обещали подумать

Я выдал еще предложение по интергации .Net - SQL (при использовании connection pooling, что почти обязательно для WEB, обрубаются возможности по connection-wide application locks, а их очень хочется иметь для блокирования документов) которое обещали записать в wish list

[alex_127]

Меня беспокоил вопрос о CLR. Отрадно, что память используемая CLR та же, что и SQL server, то есть memory intensive CLRs не будут вытеснять sqlsrvr.exe. Правда, вопрос что будет, если SQL server использует AWE (очевидно CLR не могут использовать AWE) остался без ответа

CLR "internals" are allocating memory from the buffer pool (i.e. SQL Server is aware of fact how this memory is used)
GC is NOT using buffer pool (but SQL Server is aware of the allocations)

When SQL Server sees that it is running close to the limit of available physical/virtual memory it broadcasts notification to all memory consumers - including CLR. I think right now CLR can force GC sweep and unload unused AppDomains on such notifications.

AWE handling: as I have already mentioned GC does not use buffer pool memory so it is AWE-agnostic. Memory used by CLR internals (and plans) never remapped.

Тем не менее ряд вопросов до конца я не понял. Я спросил нет ли проблем с убиванием коннекций который выполняют CLR по kill или в результате deadlock. Они стали спорить между собой, из обрывков разговоря я понял что хотя в презентации Power Point написано что все OK, но в результате порчи каких то shared state все может быть совсем плохо. Кроме того, сервер пытается сам убить 'runaway CLRs', но что такое runaway ? Не до конца понятно как ненароком не убить просто долго считающий процесс

It is fairly complicated. I would say that post Beta2 we may need to do some adjustment in the way we are doing it but I hope that the current implementation would be sufficient. We rely on the same mechanism as SQL to deliver ATT/KILL signal to the target thread, but then it becames more interesing and have more cases. Basically it works in 2 steps: first we need to inform CLR that this thread is about to be aborted. If the thread is on active scheduler (currently running) CLR will do some majic with the thread context so it will get an exception ExecutionAborted raised from the context of the thread (details are too long). Otherwise if the thread is currently waiting within SQL or on SQL-hosted synchronization object CLR will ask SQL scheduler to resume execution of this thread and it will raise an exception itself based on retcode
Killing on the deadlock (you meant case of deadlock-detectable CLR objects?) shoud be safe. You will get a deadlock exception.
I'm not sure what they meant by "shared state" - I'm no CLR expect. CLR internal state supposed to remain consistent.

Я упомянул про то что неплохо бы поиметь приоритеты процессов и чтобы один table scan для reporting не вышибал напрочь кеш из под OLTP. Они переглянулись и засмеялись: оказывается, я не первый и не сотый кто просит о том же

Righhhtttt....

Вопрос про то что зачем на dedicated server for SQL server система NT подрезает память серверу если он не активен (weekend), в итоге к понедельнику он становится совсем маленький и IIS дает кучу таймаутов остался в общем без ответа. Обещали подумать

It is not a question of why, it is called standby list erosion. BTW, theoretically it shouldn't happen with AWE enabled - but I have never tried that.

[Dmitry67]

Да, с AWE процессы не усекаются
К сожалению с AWE Другая проблема, при использовании кластера можно использовать только 50% памяти... очень обидно
Кроме того, жта проблема снова всплывет в SQL 64bit

[Sergey___K]

А вы про User Defined Aggregate Functions не спрашиывали? А то они обещались. И еще, я бы спросил, какой умник придумал все те ограничения на функции, что есть в SQL 2k. У меня недавно было много чего сказать.

То что Yukon делает с XML это круто

А что я говорил. Толкько на это надо в полной завязке глядеть. Не только как замена nested наборов данных.

[Dmitry67]

Про аггрегаты говорили
Но там у аггрегатов только один параметр
То есть корреляцию вы не напишете

[Merle]

Я наконец услышал - слава Богу - то о чем сам долго говорил. CLR не пишутся для того чтобы их использовали ВМЕСТО SQL. Переводите текст, превращайте .JPG в GIF в CLR, но не надо переписывать insert ... select на C#. Хорошо что в Microsoft это четко понимают. К сожалению слишком много энтузиазма среди девелоперов - типа вот больше не придется писать на этом ugly TSQL !

Это не правильные девелоперы.. Ясен хвост, что для реляционных данных лучше SQL'я еще пока ничего не придумали...

Обещаны богатые средства статистики, прифилирования SQL profiler итд для CLR

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

Не до конца понятно как ненароком не убить просто долго считающий процесс

А какие могут быть с этим проблемы? Дедлоки-то отслеживаются не по time-out'у... Единственное, на что можно нарваться - это распределенный дедлок, в случае если CLR-код, сам по себе блокирует какие-то ресурсы не завязанные на БД (файл, например), и часть графа ожидания окажется вне поля зрения deadlock-монитора, но эта опастность есть и сейчас...

Я упомянул про то что неплохо бы поиметь приоритеты процессов и чтобы один table scan для reporting не вышибал напрочь кеш из под OLTP.

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

(при использовании connection pooling, что почти обязательно для WEB, обрубаются возможности по connection-wide application locks, а их очень хочется иметь для блокирования документов) которое обещали записать в wish list

Good, дело хорошее..

Вот по поводу имплементации CLR, есть ряд вопросов.
1. Если я правильно понимаю, Youkon выйдет с фреймворком, в котором будут generics, но, на PDC'шной альфе юкона создать, например, агрегат на основе генериков мне не удалось, хотя эта функциональность была бы довольно полезной.
2. При создании пользовательского CLR типа, практически весь ООП приходится забывать, например наследование не поддерживается, объявив столбец типа A, положить в него наследников этого типа не получится.
Это не доработки PDC'шной альфы, нехватка времени или есть какие-то принципиальные ограничения не позволяющие реализовать эту функциональность?

[Dmitry67]

Merle, если мне не изменяет память то раньше Вы были "Oracle guy"
Так что же, РОДИНУ ПРЕДАЛИ ?

[Merle]

Merle, если мне не изменяет память то раньше Вы были "Oracle guy"

Нет, Дима, что-то Вам изменяет..
Я всегда старался быть "unaffected guy", но больше тяготел к MSSQL'ю, поскольку с ним работать больше приходится..