| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Microsoft SQL Server |
  |
||
| Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 вперед Ctrl→ все |
 Re: Параллельные вычисления для TSQL.
|
|||||||||||
|
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
 Вы будете смеяться, но репликация это механизм, решение некоторой задачи, которая стоит выше. Давайте сразу поднимемся как можно выше.Данный механизм, как и любой механизм имеет свой набор преимуществ и недостатков - такова его природа, заложенная создателем.
Почему записи имеющие единую "транзакцию" лежат разделено? Почему записи просты (только I/U/D по одной строке)?
Почему они используют именно этот механизм?
SB - чертовски простая вещь. Ещё не могу понять, у MS уже есть репликация. Возможно (скорее всего) она не к месту для этой задачи, с её текущими возможностями. Может стоит сформулировать вопрос именно в этом направлении.
|
||||||||||
| 2 апр 11, 19:48 [10461732] Ответить | Цитировать Сообщить модератору | |||||||||||
| Re: Параллельные вычисления для TSQL.
|
|
|
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Не, ну конечно можно говорить часами, как можно ускорить этот процесс "репликации" и какие заложить в него эвристики (их куча). Решая туже задачу: Как оптимально распределить решение в пространстве и времени. |
| 2 апр 11, 20:00 [10461752] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|
|
МуМу Member Откуда: Сообщений: 1134 |
Сейчас я занимаюсь больше стратегией и управлением, а раньше в " полях" работал на проектах связанных с повышением производительности и с онлайн обменами большими данными(лично я курировал более 50-и проектов). Эти проекты были у клиентов. То есть системы разрабатывались не мной. Чего и как было исторически меня интересовало мало. Нужно было как правило получить здесь и сейчас результат, в нужный срок и нужный бюджет. Поэтому рассуждения на тему как распределить решения в "пространстве и времени" это оставляем для чистых теоретиков. Я могу так сказать что для системы репликации важен вопрос унификации. Не было как правило времени(бюджета) анализировать как можно изменить функционал клиента или тем более бизнеспроцессы клиента. Система должна быть надежной , легко управляемой и производительной. Есть вполне измеряемые вещи к которым при разработки мы стремились. Например скорость обмеена,время задержки - многопоточность в этом варианте просто жизненно необходима. Я понимаю что можно обойтись другими способами - но это извините, бизнес. Насчет того почему не используем стандартные механизмы? - на это есть своя причина. Но могу сказать так - вели переписку с разработчиками из рейдмонда(некоторые ошибки скидывали). Решение стандартное было разложено просто до винтиков. В том числе я выступал не раз на конференциях и втом числе на MSSQL club на тему типовой репликации. Поэтому не хотелось бы вдаваться в дискуссию почему мы используем свой механизм. Это тема немного другая. |
| 2 апр 11, 22:47 [10462294] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|
|
МуМу Member Откуда: Сообщений: 1134 |
Это была предистория. Теперь по существу. Во первых по поводу транзакции. Я вам скажу с практической точки зрения. Пускай система работает надежно 99 процентов времени, но потом происходит перезагрузка сервера и т.п. В этом случае есть шанся того что определенная часть "разделенной" транзакции окажется не примененной. Есть конечно свой "лог", есть инструменты для автоматического наката, есть верификация и т.п. но они имеют ряд недостатков. Сервис может почему то не запуститься, "накат" может не пройти потому что уже произошел конфликт и автоматичеки это сделать нельзя и т.д. и т.п. Рассказывать клиенту о всех этих особенностях поверьте дело неблагодарное. Для клиента все просто. На одном севрере данные одни а на другом другие(на некоторый интеравл времени). Все остально его не волнует. |
| 2 апр 11, 22:55 [10462327] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|
|
МуМу Member Откуда: Сообщений: 1134 |
Что касается записей.Почему они находятся в разных записях? Принцип простой. Автоматически генерируются триггеры. Эти триггеры добавляют записи в таблицы об измененных данных.Можно было бы писать в блоб поля и т.п.(вплоть до того что даже сжимать сразу) но это влияло бы на основную систем что не допустимо.(система репликации должна отбирать производительности не более 10%). Для создания своей транзакционной репликации других инструментов от микрософт нет. |
| 2 апр 11, 23:01 [10462349] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|
|
МуМу Member Откуда: Сообщений: 1134 |
Теперь что касается длинных транзакций. У клиента есть мониторинг как производительности, так и репликации. Система постоянно оптимизируется. Но тем не менее иногда у него возникают действительно "большие" транзакции. Т.е. допустим происходит в транзакции куча апдейтов за длительный интервал времени. На основную систему это не влияет потому как блокировок не создает. В ряде случае апдейты идут массовые а репликатор их иногда применяет по записи в силу объективных причин(и давайте на эту тему хотя бы не спорить а то спор вообще уйдет в другую тему). Если эти изменения применять в одном потоке - подобная транзакция введет большое время рассинхронизации. Что разумеется не приемлимо. В общем почему длинные транзакции ? - Так сложилось, объективно нужно и самое главное я на это влиять не могу! |
| 2 апр 11, 23:07 [10462371] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|
|
МуМу Member Откуда: Сообщений: 1134 |
Насчет Service Broker. Извините, но я нигде не говорил что применять его сложно! Посмотрите переписку , эта фраза принадлежит не мне. Давайте рассмотрим следующий пример. Обращается ко мне клиент. Вот система тормозит. Включаем мониторинга и т.п. Проводим линейную оптимизацию(индексы, запросы и т.п.) Сразу скажу, что структуру как правило менять существенно нельзя- нет времени, нет бюджета. Затем видим что основной вариант для оптимизации это распараллеливание(как правило для регламентных задач). Предположим что весь код на T-SQL. На данный момент после этого необходимо бить код на части после чего он становиться не читабельным и плохо споровождаемым. Реализовывать координатор соединений. Реализовывать интерфейсы взаимодействия. Предусматривать вопросы некорректной обработки, аварийных отключений и т.п. Что было бы идеально. Для этого кода включаем специальный режим. Далее использую синтаксис от MSSQL указываем в коде что можно паралеллить а что нельзя, прописываем интерфейсы(но они будут более унифицированными), указываем параметры для координатора потоков.(сколько максимально потоков открывать, и т.п.). Вообщем была бы большая унификация а также вопросы связанные с координацией потоков мог бы для ряда задач взять на себя MSSQL. Ну и про транзакции не забываем, все накатывал-откатывал бы автоматом сервер. Подобные проблемы редко - но выстреливают. |
| 2 апр 11, 23:19 [10462428] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|||||||||||||||||||||||
|
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
А вот теоретики пусть и занимаются унификацией и мага-универсальными
Боже сколько воды, соплей, кичась налево и направо, мать родная. И пока мы видим один лишь невразумительный пример.
После перезагрузки состояние системы будет ровно такой же, как до падения сервера - полностью. И части этих кусочков продолжатся сначала восполняя всю мозаику до конца. Меня больше всё ужасает то, что вы приводите аргументы которые применимы к любому подходу. Какая разница, не прошла одна транзакция и ста или ваша одна единственная. Пост пролетел как фанера. Перейдём к следующему.
Что вы скажете об этом. Надеюсь я правильно понял, читая между строк. Ощущение, что вы пытаетесь конкурировать с самим MS на их же поле. Зачем?! Если вас не устраивает какая-то мелочь в их продуктах (репликация/зеркалирование/нотификации и т.п.) - требуйте её, а не эти непонятные "параллельные вычисления".
Ставим линию разрыва, из-за бесполезности всего выше сказанного. ------------------------------------------------------------------------------------------------------------
Две крайности: существенные изменения <-> надуманные оптимизации. И ничего между ними. А между ними то бесконечность. Вы что эти 50 проектов в режиме copy-paste делали? Нет, я конечно могу понимать реалии корпоративной убогости систем, но если проект не имеет шансов, туда ему и дорога. Ведение проектов это вам не в приферанс играть. Хотите выжить, думайте заранее, какие проблемы могут возникнуть заранее известно ещё на стадии проектирования.
Эм. И к чему пришли. Если я правильно понял вашу задачу, как автоматизация продления жизни говно-кода. Могу сказать, смотря в эту абстрактность, что написать такую обёртку использующую SB со всеми транзакциями вроде не сложно, и будет вам унификально. Но требовать это из каропки от MS идиотизм. Вы можете это попросить у оракакла, но мелкие на это не поддадутся (во всяком случае так было до этого), тем более что никакого профита. Они не будут рыть яму себе, повышая уровень мелких некомпетентных клиентов. Нет денег на нормальный IT - сдохни, но мы не благотворительная компания. |
||||||||||||||||||||||
| 3 апр 11, 02:19 [10462695] Ответить | Цитировать Сообщить модератору | |||||||||||||||||||||||
| Re: Параллельные вычисления для TSQL.
|
|
|
МуМу Member Откуда: Сообщений: 1134 |
То Mnior Извините но на демагогию у меня нет времени. Вы говорите про конкретику, но ваши сообщения сводятся к тому что не нужно писать говнокод и т.п, я привильно понимаю? То есть вы смотрите со стороны исключительно разработчика которого вопросы бизнеса а в частности рентабельности и прибыли не интересуют абсолютно. У нас работают специалисты высокого уровня, тем не менее в некоторых программных продуктах пишется код мягко говоря не самый "оптимальный". В большинстве случаев это делается сознательно, потому как еще есть сроки за которые спрашивают. Есть еще бизнесплан с предпологаемой жизнью продукта. Поэтому утверждение о том что каждый разработчик должен писать "идеалный" код оставим для идеалистов. В тех же штатах очень много устаревших и тем не менее крупных и работающих ИТ систем. Их почему то никто не торопиться менять. Потому как затраты очень и очень большие, и простои от остановки ИТ системы в переходный период период могут вообще закрыть бизнес. Я вам привел конкретные аргументы, от вас таковых не получил. Поэтому предлагаю вам в моей ветке больше не дискутировать. Будем считать что я вам не смог объяснить. А примеры кода с своими предложениями, как я уже говорил, обязательно выложу, Если будет интересно потом почитаете. |
| 3 апр 11, 09:53 [10462794] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|||||||||||
|
alexeyvg Member Откуда: Moscow Сообщений: 31813 |
Конечно, если БЛ выносить наружу, то проблем нету - на сервер СУБД посылаются только одиночные запросы, сервер их прекрасно распаралеливает, всё остальное (основное) распаралеливание берёт на себя сервер приложений. Но если логика работы с данными лежит в СУБД, то ситуация другая. К серверу идут запросы (вызовы ХП). Запросы средней сложности, ракспаралеливаются не всегда, к тому же распаралеливание ограничено теоретически (не всегда запрос можно будет эффективно распаралелить на тыщу потоков). Вполне можно расщепить потоки ещё в несколько раз.
|
||||||||||
| 3 апр 11, 10:29 [10462829] Ответить | Цитировать Сообщить модератору | |||||||||||
| Re: Параллельные вычисления для TSQL.
|
|||
|
alexeyvg Member Откуда: Moscow Сообщений: 31813 |
Сиквер должен выполнять только одиночные запросы, всё остальное должен делать клиент или сервер приложений. При таком подходе действительно ничего менять не надо, всё и так хорошо. Но вот общепринятым преимуществом оракла считается то, что на нём можно писать бизнес-логику, обрабатывать данные, и, например, в банковских системах именно поэтому он более популярен. И вот как раз совершенствование средств работы с БЛ (не только распараллеливание) я считаю важной задачей для разработчиков сиквела. |
||
| 3 апр 11, 10:42 [10462842] Ответить | Цитировать Сообщить модератору | |||
| Re: Параллельные вычисления для TSQL.
|
|||||||||||||||||||||||
|
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Есть говно-код написанный недо-программистом и говно-код написанный профессионалом (неоптимальный). Разница в том, что во втором случае известно где и куда и как копать в сторону оптимизации и у него "остаётся место для разворота". Т.е. ПМ управляет будущей архитектурой системы согласно составленным планам и срокам. Если этого нет, то значит даже и тупой говно-код скорее всего пишется не в сроки. Планы и сроки не заканчиваются сдачей проекта, туда включены и планы и сроки и методы по его допиливанию. Этим бизнес и управляет. А когда ВНЕЗАПНО прибегают, у нас бяда, Houston, we have a problem. А если ещё при этом бюджет нулевой. То повторяю - ничего не поможет, хоть имея 100500 механизмов включая этот. Это было конкретно описано в конце моего предыдущего поста.
На какой аргумент не отвечено конкретно?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Считаем аргумент с конём засчитан? Нужно не просто предполагать что что-то там можно распараллелить и мечтать об этом, нужно чётко знать как это можно сделать во всех встреченных местах кода. Это раз. И чётко высчитать, что затраты на изменение кода в параллельность дешевле чем изменение кода в оптимальность или другие имеющиеся N подходов, притом с затратами бизнеса и на будующее. Это два.
Но не люблю крайности. Да, сейчас модно вообще всё выносить из СУБД, и меня крайне бесит, когда это пропагандируется как единственный верный путь. Просто постоянно встречаются случаи когда пихают в сервер всё подряд и логику конкретного клиента. Архитектура системы требует расслоений. И в сиквеле должна быть сосредоточена бизнес-логики логической модели, т.е. отражение логической модели на физическую (схему данных). Всё что выше интерфейса логической модели системы должно быть вынесено в сервер аппликейшн и клиент, там сосредоточена логика взаимодействия и отображения. Так что ваши дальнейшие предположения были не верны.
Давайте я за вас сформулирую: Существую вещи которые можно распараллелить, но автоматизировать это нельзя. Замечательно. Но я привёл аргументы выше:
 Повторю ещё одну вещь, которую я вижу постоянно. Если вы что-то делаете очень много раз, вы в итоге это делаете в 100500 раз быстро и качественно. Что до этого считалось немыслимо дорого по сравнению с другими вариантами, после считается наоборот - непомерно дёшево. Поэтому нет одинаковых бизнес планирований. Поэтому чаще выступаю за оптимизацию кода, а не за закрытие на это глаза. Если вам надо выиграть время, SB должен помочь, как временное решение. |
||||||||||||||||||||||
| 3 апр 11, 15:17 [10463568] Ответить | Цитировать Сообщить модератору | |||||||||||||||||||||||
| Re: Параллельные вычисления для TSQL.
|
|
|
МуМу Member Откуда: Сообщений: 1134 |
То minor. Я понял ваши аргументы но меня они не убедили, как впрочем и мои видимо вас. Еще раз повторюсь, если приложение легко оптимизируется линейно - это самый правильный путь. Я говорю про класс задач в которых только линейной оптимизацией не справиться. Сейчас такие задачи решаем и решаем успешно, правда как правило управление распараллеливанием реализовывается на уровне приложения. Чего не хватает? Один из примеров я уже написал и напишу его еще раз ниже.(насчет распараллеливания в одной транзакции) Что еще не хватает? Того что бы прийти к клиенту посмотреть только T-SQL код - линейно оптимизировать его а если уже дальше не получается взять и с минимальными трудозатратами изменить таким образом что бы использовалось распараллеливание. Причем целиком и полностью на T-SQL, что бы это было читабельно и что бы можно было бы легко сопровождать клиенту. Вы скажете что слишком вообщем? - Я уже сказал что чуть позже(думаю в течении недели) я напишу конкретные предложения с конкретными примерам. Напишу один из примеров - конкретно что мне нужно. Есть открытых N сессий. Я указываю конструкцию по которой говорю что все эти сессии нужно связать(например spid-ы передаю, и какой нибудь уникальный идентификатор "обобщенной сессии"). После этого все блокировки в рамках сессий воспринимаются как общие, все изменения этих сессий идут в единой транзакции(т.е. если откатывается одна то откатываются все остальные) и что самое важное - они могут выполняться параллельно. |
| 3 апр 11, 15:44 [10463649] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|
|
locky Member Откуда: Харьков, Украина Сообщений: 62034 |
в 99% случаев желание "распараллелить" проистекает от нежелания оптимизировать, в частности - хотя бы немного подумать об индексах, о формальной оптимальности кода и т.д. |
| 3 апр 11, 15:53 [10463682] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|||||||||
|
alexeyvg Member Откуда: Moscow Сообщений: 31813 |
Что, если возникает идея, то её нельзя озвучить, пока не появился нормальный востребованный продукт, её реализующий??? Кстати, непонятно, почему вы так-же яростно не выступаете против других внедрений распараллеливания, например в PDW или в SQL Azure??? Видимо, просто ничего уже не поделать, продукты продаются и остаётся только горько рыдать? :-) И зачем покупают этот PDW за 10 лимонов, нужно просто сделать "изменение кода в оптимальность или другие имеющиеся N подходов" :-)
Этот путь не заменят никакие другие подходы (кроме распараллеливания на уровне сервера приложений). Нету никаких "другие имеющиеся N подходов". Точнее, может и есть, но как быть, если всё что можно уже сделано?
Бывает, знаете, люди пишут код не хуже вас (представляете???), и он вполне оптимальный. Но вот беда - потоков выполнения от клиента только 10 (ну просто пользователей столько), а ядер 100, и загружается только десятая часть ресурсов. А через 10 лет ядер в типичном дешёвом сервере будет 1000, и будет ещё хуже. Сейчас то обычно для потока тяжёлых запросов делается распаралеливание на уровне запроса, но при увеличении ядер это будет работать всё хуже и хуже. |
||||||||
| 3 апр 11, 15:59 [10463704] Ответить | Цитировать Сообщить модератору | |||||||||
| Re: Параллельные вычисления для TSQL.
|
|
|
МуМу Member Откуда: Сообщений: 1134 |
То locky. Поверьте это не про меня. У компании более 250-и проектов по оптимизации у крупных корпоративных клиентов. Задача линейной оптимизации поставлена на поток. Есть свои средства мониторинга которые показывают сколько дает вклад в нагрузку конкретная строчка кода(это поверьте не так уж тривиально) и многое,многое другое. Есть люди которые занимают отдельно вопросами оптимизации индексов и запросов, есть которые занимаются вопросами разработки оптимальной структуры, блокировочными механизмами, моделирования нагрузки и т.д. и т.п. (Есть даже экспертная система который парсит переданные из мониторинга тяжелые запросы после чего предлагает возможные варианты оптимизации запросов автоматом.) Просто есть класс задач который после линейной оптимизации кроме как распараллеливанием эффекта существенного не дает. |
| 3 апр 11, 16:02 [10463712] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|||
|
alexeyvg Member Откуда: Moscow Сообщений: 31813 |
И главное, (МуМу тоже писал) - сиквел покупают и используют совершенно не для написания оптимизированного кода, а для получения бабла. Только! для получения денег, больше ни для чего. Если выгоднее нанять студента, который с третьей попытки сумеет заменить 2 последовательных вызова кривых процедур без индексов и с курсорами на 2 параллельных вызова тех же кривых процедур, пусть даже это приведёт к сайд-эффектом и данные нужно будет править руками раз в месяц - то это и надо сделать - при условии, что это выгоднее для бизнеса. И тот, кто поступит по другому - будет последний непрофессионал. Профессионал принимает решения исходя из требований бизнеса, а не исходя из красивости кода. А тот, кто предоставит для этого инструменты, и будет лидировать на рынке СУБД :-) Это не значит, что весь код должны писать студенты и что обязательно они сделают плохо, но очень часто бывает именно так и часто это правильно. |
||
| 3 апр 11, 16:12 [10463750] Ответить | Цитировать Сообщить модератору | |||
| Re: Параллельные вычисления для TSQL.
|
|
|
locky Member Откуда: Харьков, Украина Сообщений: 62034 |
alexeyvg, значит нужно развивать инструменты для формального анализа кода для t-sql, коих увы на рынке нет для того же шарпа есть решарпер, который мала-мала, но кривые и косые места (да, не все) показывает и подсказывает. Да и, если мне не изменяет маразма, для си/шарпа/паскаля было много тулов по статическому анализу кода а для скуля последним был MSBPA, для 2000, кажется. |
| 3 апр 11, 16:15 [10463764] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|||
|
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37198 |
Элементарный пример: пишем "идеальный" код, состоящий из апдейта двух больших таблицы по двум маленьким темповым (джоин по ключам с обеих сторон, да) в одной транзакции. Формальный анализ покажет, что все ок. Однако, копаем глубже, и выясняем, что две большие таблицы лежат в разных файлгруппах (которые лежат в свою очередь на разных физических носителях, сопоставимых по загрузке и производительности) и, тупо, запустив эти запросы параллельно, мы получим двукратный прирост производительности (при условии, что лог и темпдб не лажают; пусть, для простоты, не лажают). Вот тут и начинаешь думать, нужна ли эта целостность с этой общей транзакцией, или может ну ее, джобами параллельно зафигачим?.. Сообщение было отредактировано: 3 апр 11, 21:14 |
||
| 3 апр 11, 21:13 [10464472] Ответить | Цитировать Сообщить модератору | |||
| Re: Параллельные вычисления для TSQL.
|
|
|
locky Member Откуда: Харьков, Украина Сообщений: 62034 |
Гавриленко Сергей Алексеевич, скажем так. тот факт, что нельзя однозначно и гарантированно покрыть 100%, и даже 90% кодо-случаев вовсе не означает, что не надо стараться/пробовать покрыть хотя-бы 30-40% случаев. потому как случаи бывают крайне разные, иногда даже вопиющие. |
| 3 апр 11, 22:03 [10464650] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|||
|
alexeyvg Member Откуда: Moscow Сообщений: 31813 |
|
||
| 3 апр 11, 22:41 [10464870] Ответить | Цитировать Сообщить модератору | |||
| Re: Параллельные вычисления для TSQL.
|
||||||||
|
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
locky, спасибо что присоединились.
Лично я выступал (неоднократно) в сторону другого Сразу отвечу на последующие аргумент: Код либо связан логически (и физически, значит оправдано), или логика связывания вынесена на аппликейшн (а там уже есть механизмы), или они не в одной "транзакции". Так вот, это даст лимон преимуществ: По сути мы то и делаем в коде, что логический набор режем в последовательность команд по физических данным (таблицам). Зачем?!
Только если эти изменения раздельны, то данные будут разные от случая, а если изменения связаны одной командой, то данные всегда есть в наличии - цельные (см MERGE), но нет инструментов регулирования последовательности запуска триггеров, а это очень старая больная тема (см ещё OUTPUT). |
|||||||
| 4 апр 11, 01:54 [10465385] Ответить | Цитировать Сообщить модератору | ||||||||
| Re: Параллельные вычисления для TSQL.
|
|
|
_r2003 Member Откуда: Владивосток (Москва) Сообщений: 56 |
А что такое большая транзакция? это сотня мегабайт данных или миллион строк или её длительность час. |
| 27 июл 11, 12:14 [11033090] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|
|
_r2003 Member Откуда: Владивосток (Москва) Сообщений: 56 |
http://msdn.microsoft.com/ru-ru/library/ms131686.aspx http://msdn.microsoft.com/ru-ru/library/dd776382.aspx http://msdn.microsoft.com/ru-ru/library/bb510625.aspx |
| 27 июл 11, 12:33 [11033214] Ответить | Цитировать Сообщить модератору | |
| Re: Параллельные вычисления для TSQL.
|
|||
|
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37198 |
|
||
| 27 июл 11, 12:34 [11033220] Ответить | Цитировать Сообщить модератору | |||
| Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 вперед Ctrl→ все |
| Все форумы / Microsoft SQL Server | |
|
x