Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: outer apply  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
a_voronin
Гавриленко Сергей Алексеевич
пропущено...
Из вашего пассажа я могу сделать лишь вывод, что у вас лучше всех в вашей компании работает палец, которым вы тыкаете в небо: чаще попадаете, куда надо.

В этом способе (и способности) ничего криминального я не вижу, но выглядит очень странно, что вы обвиняете в непрофессионалами тех, кто пользуется более логичными способами.


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

a_voronin
Понятно, что HASH JOIN может оказаться лучше индекса. Непонятно, почему оппонент решил, что я что-то имею против.
С ваших же слов:
a_voronin
То, что у вас возникает Hash и индекс ему не помогает, это означает лишь одно, что индекс вы выбрали неправильный.


a_voronin
Но я повидал слишком много "магии", когда что-то не работает согласно документации (магии в коде, которые писал как правило не я), чтобы согласиться с тем, что все всегда логично.
У каждой "магии" есть причина до которой можно докопаться в 99% случаев, ну или хотя бы спросить на форуме у более опытных коллег.
11 июн 14, 03:42    [16152114]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
Я рад за тех, у кого чутьё есть. И я рад за тех, кто умеет читать планы. Никого не хочу обидеть, просто с позиции своего опыта, хочу сказать, что планы действительно могут быть разными. Возможно сейчас на 2012 планы стали более предсказуемыми, но 2000/2005 и Oracle 10g, которыми я имел дело в период с 2004 по 2011 дело не всегда было предсказуемо. Сейчас я больше OLAP занимаюсь, ну и SQL Server 2012 касаюсь по ходу дела.

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

Только вот, от его самодеятельности уже через 12 часов портал стал ложиться, ему вставили люлей и джобу вернули на место. Работает до сих пор система с 1999 года. http://instantsurvey.com/
11 июн 14, 12:43    [16153927]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Glory
Member

Откуда:
Сообщений: 104751
a_voronin
Только вот, от его самодеятельности уже через 12 часов портал стал ложиться, ему вставили люлей и джобу вернули на место.

Вы хотите сказать, что автоматическое обновление статистики не работает ?
Или что принцип его работы не подходил для этой системы ?
Или что в каждой системе может быть свой подход к обновлению статистики, включая и стандартное автоматическое обновление ?
11 июн 14, 12:53    [16154012]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
Я хочу сказать, что автоматическое обновление статистики не помогало нескольким запросов. Там происходили вбросы крупных объемов данных в очень большую таблицу. И там где требовался HASH JOIN , оставался NESTED LOOP. И да автоматическое обновление статистики этим нескольким запросам не помогало. Над проблемой бились лучшие умы включая директора компании.

В конце конце пришли к выводу, что наличие этих созданных руками статистик и их регулярное обновление проблему решает. При этом неоднократно была такое, что кто-то приходил с заявлениями "Вы хотите сказать, что автоматическое обновление статистики не работает ? Или что принцип его работы не подходил для этой системы ?" и заваливал систему.

А вот "Или что в каждой системе может быть свой подход к обновлению статистики, включая и стандартное автоматическое обновление ?" Мой ответ да может. В высоконагруженной системе может потребоваться иметь несколько нестандартных подходов к статистике.
11 июн 14, 13:26    [16154242]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Glory
Member

Откуда:
Сообщений: 104751
a_voronin
Я хочу сказать, что автоматическое обновление статистики не помогало нескольким запросов.

Т.е. оно(автоматическое обновление) таки работало ?
11 июн 14, 13:32    [16154279]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
Glory
a_voronin
Я хочу сказать, что автоматическое обновление статистики не помогало нескольким запросов.

Т.е. оно(автоматическое обновление) таки работало ?


Естественно оно работало. Я где-то сказал, что оно было совсем бесполезно? Я сказал, что в нескольких редких, но важных, случаях оно не помогало.
11 июн 14, 14:18    [16154637]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Glory
Member

Откуда:
Сообщений: 104751
a_voronin
Glory
пропущено...

Т.е. оно(автоматическое обновление) таки работало ?


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

С ваших слов получалось, что кому-то "вставили люлей" потому, что автоматическое обновление статистики не работало так, как написано в хелпе.
11 июн 14, 14:21    [16154663]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
Glory
a_voronin
пропущено...


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

С ваших слов получалось, что кому-то "вставили люлей" потому, что автоматическое обновление статистики не работало так, как написано в хелпе.


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

Смотрите в чем была ситуация. Есть таблица А 1 ко многим к таблице Б.

По определенному ID-шнику в таблице А сначала в таблице Б 5-10 записей и план ориентирован на то, что записей в JOIN будет немного. В какой-то момент происходит резкий вброс данных, по этому ID-шнику уже 50000 связных записей. Всего в таблице 100+ лямов записей. Так вот, автоматическое обновление статистике не успевало подхватывать эту ситуацию. REFERENCE был убит потому что с ним тоже всё ложилось, а индекс естественно был. Так вот без автоматического обновления статистики, которое давало информацию, сколько по каждому ID есть связных записей действовал старый план.
11 июн 14, 14:32    [16154728]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Glory
Member

Откуда:
Сообщений: 104751
a_voronin
Ему вставили люлей за то, что он своей шипкой умностью, положил систему. Когда уже давно было известно, что автоматическое обновление статистики не помогало. Если предлагаешь решение, то предлагай так, чтобы система работала. Тогда бы я ему проапплодировал. Но он посчитал, что умнее остальных, и положил систему.

Ааа, понятно. Т.е. это рассказ про то, как люди не умеют пользоваться стандартными решениями или не знают, как они работают.
11 июн 14, 14:37    [16154779]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
Glory
a_voronin
Ему вставили люлей за то, что он своей шипкой умностью, положил систему. Когда уже давно было известно, что автоматическое обновление статистики не помогало. Если предлагаешь решение, то предлагай так, чтобы система работала. Тогда бы я ему проапплодировал. Но он посчитал, что умнее остальных, и положил систему.

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


Можно я задам вам вопрос, а вы бы смогли предложить предложили хорошее решение? Речь шла о продукте, разработку которого америкосам продавали за большие бабки. И среди клиентов были Adobe, TMobile, Microsoft, Expedia и ещё списочек не хилый. Мне вот интересно, чтобы вы "стандартного" предложили.

У меня, если что, есть еще одна история, когда этот админ выпенрился второй раз, предложил нашему директору меня уволить, потом завалил всю работу и тогда, его уволили.
11 июн 14, 14:42    [16154846]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Решение с пересчетом статистики в джобе - плохое. Хотя бы потому что ненадежное, потому что может прийти какой-то админ и его отключить. Или вообще агента отключить. Да и регулярный пересчет статистики - не единственный способ фиксации скачущих планов.
11 июн 14, 14:58    [16155025]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Glory
Member

Откуда:
Сообщений: 104751
a_voronin
Можно я задам вам вопрос, а вы бы смогли предложить предложили хорошее решение?

Одного наилучшего решения на все случаи жизни не существует.
Лечить по фотографии "умел" только Кашпировский.

a_voronin
У меня, если что, есть еще одна история, когда этот админ выпенрился второй раз, предложил нашему директору меня уволить, потом завалил всю работу и тогда, его уволили.

Поэтому, все, о чем он читал в хелпе и пересказывал, можно считать неправильным и непригодным ?
11 июн 14, 14:59    [16155039]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
a_voronin
У меня, если что, есть еще одна история, когда этот админ выпенрился второй раз, предложил нашему директору меня уволить, потом завалил всю работу и тогда, его уволили.

Поэтому, все, о чем он читал в хелпе и пересказывал, можно считать неправильным и непригодным ?[/quot]

Потому что читать хелп недостаточно. Надо пробовать на практике.
11 июн 14, 15:03    [16155085]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
Glory
a_voronin
Можно я задам вам вопрос, а вы бы смогли предложить предложили хорошее решение?

Одного наилучшего решения на все случаи жизни не существует.
Лечить по фотографии "умел" только Кашпировский.

a_voronin
У меня, если что, есть еще одна история, когда этот админ выпенрился второй раз, предложил нашему директору меня уволить, потом завалил всю работу и тогда, его уволили.

Поэтому, все, о чем он читал в хелпе и пересказывал, можно считать неправильным и непригодным ?


Рейтинг у вас большой господин Glory, знаете много, но повыпендриваться тоже любите.
11 июн 14, 15:05    [16155102]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
kalimba
Member

Откуда:
Сообщений: 297
Если память мне не изменяет то сейчас автоматический пересчёт статистики делается когда вставляется больше 20% + 500 записей.

Гавриленко Сергей Алексеевич,
А какое правильное решение тогда. Кроме нововведений в 2014ом? http://msdn.microsoft.com/en-us/library/dn600374.aspx
11 июн 14, 15:07    [16155123]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
kalimba
Если память мне не изменяет то сейчас автоматический пересчёт статистики делается когда вставляется больше 20% + 500 записей.

Гавриленко Сергей Алексеевич,
А какое правильное решение тогда. Кроме нововведений в 2014ом? http://msdn.microsoft.com/en-us/library/dn600374.aspx
Воспользоваться каким-нибудь другим способом фиксации плана выполнения. Например, поменять код и/или структуру данных.
11 июн 14, 15:11    [16155149]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4902
Гавриленко Сергей Алексеевич
kalimba
Если память мне не изменяет то сейчас автоматический пересчёт статистики делается когда вставляется больше 20% + 500 записей.

Гавриленко Сергей Алексеевич,
А какое правильное решение тогда. Кроме нововведений в 2014ом? http://msdn.microsoft.com/en-us/library/dn600374.aspx
Воспользоваться каким-нибудь другим способом фиксации плана выполнения. Например, поменять код и/или структуру данных.


Нельзя было фиксировать план. В том-то был весь нюанс, что там в разных случаях был востребован разный план. 1 к 5 NESTED LOOP 1 к 500 MERGER JOIN 1 к 50000 HASH JOIN . Я думаю решение было правильным, иметь точечную статистику, и принудительно регулярно её обновлять. Возможно проблемы не было бы, если бы был установлен REFERENCE, но его убили из-за того, что он снижал производительность.
11 июн 14, 15:43    [16155488]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Glory
Member

Откуда:
Сообщений: 104751
a_voronin
Рейтинг у вас большой господин Glory, знаете много, но повыпендриваться тоже любите.

Т.е. рассказываете о своих супер достижениях и считаете количество чужих сообщений вы, а выпендриваются другие ?
11 июн 14, 16:46    [16156031]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
OFFTOP : мдя.. появился персонаж однако
11 июн 14, 16:59    [16156126]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
a_voronin
Например, у нас была статистика созданная руками, которую принудительно обновляли джобой, иначе начинались проблемы с планами.
Да простят меня многоуважаемые старожилы форума, но конкретно в данном вопросе я буду на стороне a_voronin'а.

Гавриленко Сергей Алексеевич
Воспользоваться каким-нибудь другим способом фиксации плана выполнения. Например, поменять код и/или структуру данных.
Если проблема в неверной статистике, то почему бы не исправить это на том уровне где проблема возникает? По мне, так это, в определенных случаях, единственно правильный и при этом стандартный способ. На основании неверных статистик неправильно считается cardinality, как следствие строятся неверные планы. Запросов которые страдают от этого могут быть десятки, их что все пересматривать и переписывать? Или plan guide-ы делать? И при написании каждой новой процедуры/запроса помнить о том, что есть такая проблема и нужно код писать соответственно? Да и еще не забыть это рассказать вновь нанятому девелоперу и перепроверять весь его код? А менять структуру уже работающей системы из-за высокого порога автоматического обновления статистики, это уже вообще ни в какие ворота не лезет.

Ручной пересчет статистик вполне допустимая практика, посмотрите на тот же Sharepoint, там вообще авто-обновление/создание отключено по-умолчанию.

Авто-обновление/создание нормально работает в большинстве случаев, при этом четко в соответсвии с документацией, но тем не менее у него есть несколько критических недостатков:
1. Новые статистики создаются только по одному полю.
2. Сервер не умеет автоматом создавать фильтрованные статистики.
3. Используется sample rate вместо full scan, чего недостаточно в некоторых случаях.
4. Авто-обновления могут происходить в не совсем подходящее время, а именно при выполнении запроса, и как следствие периодические и трудноидентифицируемые "зависания" вплоть до таймаутов. Лечится включением асинхронного обновления, но оно в свою очередь имеет свои недостатки.
5. Авто-обновления происходят только при превышении порога в 20%. Исправляется флагом 2371 начиная с версии SQL 2008 R2 SP1.
6. Не делается нормальный пересчет статистики по автоинкрементым полям. Исправляется флагами 2389, 2390 начиная с версии SQL Server 2005 SP1.

a_voronin
По определенному ID-шнику в таблице А сначала в таблице Б 5-10 записей и план ориентирован на то, что записей в JOIN будет немного. В какой-то момент происходит резкий вброс данных, по этому ID-шнику уже 50000 связных записей. Всего в таблице 100+ лямов записей. Так вот, автоматическое обновление статистике не успевало подхватывать эту ситуацию. REFERENCE был убит потому что с ним тоже всё ложилось, а индекс естественно был. Так вот без автоматического обновления статистики, которое давало информацию, сколько по каждому ID есть связных записей действовал старый план.
Тут, скорее всего, причина определена не совсем верно. При расчете cardinality для таблицы B серверу фиолетово какие именно ID выбираются из таблицы А, единственное что имеет значение, это количество строк из A. Затем это значение умножается на некое усредненное отношение между A и B и получается Estimated Row Count после джойна.
Проблема наверняка была в том, что новые ID из таблицы A еще не попали в статистику, как следствие оценка неверна еще во время анализа фильтра по A. Возможно (но не факт) тут бы помогли флаги 2389, 2390.

a_voronin
Возможно проблемы не было бы, если бы был установлен REFERENCE, но его убили из-за того, что он снижал производительность.
При оценке cardinality оптимизатору наплевать на REFERENCE. Глупо, но факт


Решение с запуском SSIS пакета из джоба для выгрузки критически выжных для бизнеса данных
Гавриленко Сергей Алексеевич
- плохое. Хотя бы потому что ненадежное, потому что может прийти какой-то админ и его отключить. Или вообще агента отключить
По-моему звучит это как минимум глупо. И разницы между бизнесс задачей и ручным пересчетом статистики я лично никакой не вижу.
Как вариант, если загрузку большого количества данных делает допредленный процесс, то можно туда же и воткнуть ручной пересчет статистики как последний шаг.

kalimba
А какое правильное решение тогда. Кроме нововведений в 2014ом? http://msdn.microsoft.com/en-us/library/dn600374.aspx
А как бы это тут вообще помогло? Если даже самому совершенному Cardinality Estimation алгоритму предоставить неверные данные о статистиках рапределения, то он все равно выдаст неверный результат. Исправлять надо причину, а не следствие.
11 июн 14, 23:00    [16157303]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
a_voronin
Речь шла о продукте, разработку которого америкосам продавали за большие бабки. И среди клиентов были Adobe, TMobile, Microsoft, Expedia и ещё списочек не хилый.
Это вообще не аргумент. 90% успеха продукта зависит от маркетинга, а не от отсутствия в нем багов.
11 июн 14, 23:04    [16157317]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
kalimba
Member

Откуда:
Сообщений: 297
Mind,

В целях своего развития сделал скрипт для понимания нового CE по материалам этой статьи. Для запуска нужен SQL Server 2014 и AdventureWorks2012.

К сообщению приложен файл (New SQL Server Cardinality Estimator.sql - 2Kb) cкачать
12 июн 14, 01:04    [16157717]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Mind
По-моему звучит это как минимум глупо. И разницы между бизнесс задачей и ручным пересчетом статистики я лично никакой не вижу.
Как вариант, если загрузку большого количества данных делает допредленный процесс, то можно туда же и воткнуть ручной пересчет статистики как последний шаг.
И тем не менее, я придерживаюсь мнения, что пересчитывать именно в джобе -- решение так себе. Не подходит фиксированный план -- бывает и такое -- считайте или по окончании загрузки, или перед выборкой (не каждый раз, само собой).
12 июн 14, 01:10    [16157725]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Гавриленко Сергей Алексеевич
Mind
По-моему звучит это как минимум глупо. И разницы между бизнесс задачей и ручным пересчетом статистики я лично никакой не вижу.
Как вариант, если загрузку большого количества данных делает допредленный процесс, то можно туда же и воткнуть ручной пересчет статистики как последний шаг.
И тем не менее, я придерживаюсь мнения, что пересчитывать именно в джобе -- решение так себе. Не подходит фиксированный план -- бывает и такое -- считайте или по окончании загрузки, или перед выборкой (не каждый раз, само собой).
А где вы делаете ребилд индексов например? По мне так пересчет статистики это такой же maintenance как и ребилд индексов.
12 июн 14, 01:29    [16157752]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
a_voronin
Например, у нас была статистика созданная руками ....
И пошли сказки венского леса.
Якобы какой-то там случай может оправдать общие ложные заявления или явные совершенно не связанные с этим случаем тонны косяков.
Mind
Да простят меня многоуважаемые старожилы форума, но конкретно в данном вопросе я буду на стороне a_voronin'а.
Вот и повелись, притом не только Mind. Вы за переходами темы следите?! Смысл говорить о навязанной другой теме, которая переворачивает роли?

a_voronin, пзданул уйню (16139211), точнее во многих топиках ляпит на лево и направо. Сложилось "отношение" "у народа".
Он, на волне "отношения" подставляет "вот у меня был случай", где совершенно никто не знает в чём соль, и "нужные" нюансы выходят по ходу, но все продолжают на волне "отношение" говоря что он "не прав".

Плять как дети малые повелись, держите себя в руках и не ведитесь на провокации. Когда чел начинает это выкрутас сразу фтопку ибо не по делу и не по существу. 16145094:
Mnior
Опять 25. Это когда стали частности определять общности?

a_voronin
Нельзя было фиксировать план. В том-то был весь нюанс, что там в разных случаях был востребован разный план. 1 к 5 NESTED LOOP 1 к 500 MERGER JOIN 1 к 50000 HASH JOIN .
Да вы дорогой, сказочник однако. Любитель придумывать всё по ходу разговора.
Это вы как можете представить структуру чтобы сразу 3 возможных исхода Loop + Merge + Hash в зависимости от условий?
Они структурно несовместимы, MERGE и HASH. Наличие одного отвергает другое.

А планы можно "фиксировать" разными способами, не только обновлением статистикой или одним типом хинтов. Для каждой ситуации по разному.
И часто можно зафиксить жёстко, но хрен он признается что MERGE для любого диапазона данных будет приемлемым или даже лучшим вариантом (и/или подобрать нужный OPTIMIZE FOR, к примеру).

Так что всё это блеф и провокация, не более.

a_voronin
У вас много было систем с 100+ запросами в секунду?
Много, и есть тут редко заходящие в этот сральник люди у кого поболее будет. И ведут они себя достойно, без всякого вепендрёжа. Не говоря про то, что всякую хрень они не морозят, тем более так часто.

Да, то что тут 80% тусуются полнейших нубов в доску, и вы на голову выше чем 95% сюда заглядывающих, но даже это не оправдывает смысл чтобы кичиться.

a_voronin, а теперь соберитесь, ибо вы пришли в место где встречаются задачи, которые вам не всречались, в ситуациях, которые вам не встречались, при наличие ресурсов (человеческих и не только) которые вам не встречались, и вы должны отвечать так, что бы не навредить никому, кто может ненароком и незаметно для вас прочитать ваши посты и понять их в рамках своих обстоятельств. Тут надо уметь объяснять смысл и делать надо это аккуратно. А не выдать "решение" и сказать "Поверь мне, это лучшее".

+ a_voronin
Специально для вас я расскажу одну их важных вещей происходящую(дившую) на Физтехе. Со всей страны сходятся самые "крутые перцы", крутые в смятку , и даже если опустить, что многие обламываются на вступительных, они остаются в атмосфере где уже не самый крутой, а почти всегда найдётся в любой теме кто "вставит по самые помидоры". И если человек гордый до последнего, то его это сломает. Останутся только адекваты ...


И кто-то имеет только реальный внедрённый опыт, а кто-то умудряется воспользоваться обстоятельствами, чтобы протестить для каждого из них ещё 100 полноценных решений, на которые и не скажешь "а вот у меня был случай у заказчика", зато понимание вещей более глубокое. ...
Maxx
OFFTOP : мдя.. появился персонаж однако
Ничего, аклиматизируется и всё будет пучком.
13 июн 14, 01:01    [16160232]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить