Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 12 [13] 14 15   вперед  Ctrl
 Re: Yukon почти не виден  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
alexey_tm
StalkerS
alexey_tm

А он просто выделяет памаять по максимуму и больше ее не трогает.

Это вы про mssql ?
тогда совершенно логично выглядит заявление "скажу, что фигня это полная ваш маздай"

а я скажу, что админ MSSQL из вас - полная фигня. Хоть бы раз в документацию заглянули...


Просмотрел форумы с Вашим участием, удручает... И вызывают сомнения Ваши заявления.

Оцениваете уровень моего интеллекта, вместо того, чтобы почитать хотя-бы BOL ? ну-ну, продолжайте в том-же духе...
10 окт 05, 15:22    [1954509]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Dooma
В конечном результате имеем тот же EXE-шник в машинных кодах, выполнение которого не подходит под определение интерпретатора. Больше подходит на определение компилятора из IL.


Извините, Вы внутрь этого "EXE-ника" заглядывали. Не верите мне, поверьте Рихтеру ссылку на которого я привел чуть выше. Там галимый IL-код ничего общего с машинным не имеющий. Точно также как и в class-файлах.

На заборе тоже не дрова написано, если файл имеет PE-хидер это еще не гарантия того, что внутри машинный код
10 окт 05, 15:28    [1954541]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ChA
Member

Откуда: Москва
Сообщений: 11378
locky
Но согласитесь, truncate завсегда быстрее чем Delete. йето раз.
Безусловно, но физически это несколько разные процессы, не находите ? Заменить одно на другое даже на системном уровне не так-то просто...
locky
Когда имеем относительно небольшую вначале табличку, запросто можно нарваться на то, что менеджер блокировок заблокирует её всю (так
дешевле), и остальные процессы будут ждать. Видено неоднократно.
Не сталкивался, хотя и пользую нечто подобное. Только большой она вообще никогда не становится :) Почему такое происходит у Вас, ума не приложу, надо смотреть. Может хинтами попробовать ? Может посмотреть в сторону sp_indexoption ? Все ли там нормально ? READPAST пользовать почаще, так как "чужие" записи Вам не нужны, да мало ли...

locky
дык ведь не всегда булк применим, тут уж увы... Иногда приходится
дополнительно обрабатывать данные, причем достаточно сложным образом...
процы юзать...
Опять же, верю на слово, но не зная ситуации, предложить ничего не могу. Почти наверняка что-то можно сделать, но на это нет либо желания, либо времени, либо сил :) Хотелось бы, чтобы оно само, автоматически, читаешь, как у других, и завидуешь, но кто знает, чем приходиться платить им за эти "фичи". Перейдете на другой сервер и получите уже их проблемы, во весь рост. И опять, то нельзя, это никуда не годится... Неужели непонятно, что всяк кулик свое болото хвалит ? А у нас усугбляется еще и хулой в адрес других.

locky
Да причем тут олап, прости господи, что-ж вы его кругом все тулите. Понимаю, слово красивое и направление модное. Но посчитать сальдовку по 500К+ счетам это не поможет, не правда-ли?
Этому слову 100 лет в обед :) Простите, но не уверен, что "сальдовку по 500К+ счетам" надо делать непременно на весьма активной OLTP, а потом удивляться, что это у нас все тормозит. Не говоря уж о том, что наверняка это нечастая операция, и, более чем наверняка, ее можно посчитать в другое время. Или хранить посчитанные данные заранее, и в нужный добавлять только неучтенное.
Log-shipping на другой сервер, наконец, пусть там считают. Да мало ли способов...
Вы всерьез полагаете, что на любой из других СУБД "сальдовка по 500К+ счетам" будет "летать" ?

locky
для того чтобы разносить всё на разное железо - на
железо надо денюжки, и немалые подчас. с другой стороны, в некоторых
продуктах (не будем тыкать пальцами) эти проблемы решаеются бесплатно
путем изменения настроек.
И потом... "Делайте хоть что нибудь!" Дык делаем, работа то должна
работать, какие бы проблемы у меня лично не возникали, не правда ли?
Просто хочется проще как-то, душевнее...
Желание получить дешевше, да числом поболе, вполне понятно, но неужели Вы верите в чудесную опцию, которую установив, сразу получишь ракету ? Если даже так, то почему она сразу не установлена ? По приколу, чтобы админу было чем заняться на досуге ? В чудеса-то верить не поздно, возраст-то поди уже не тот ? :)

locky
Перейти на чо-нить другое? Ну, знаю их куда хуже (знаю что они есть, но как с йими работать...), потом, у них и своих проблем валом, если не
сказать больше... у меня ведь цель - не сбежать или охаять, а получить в
MS как можно более подходящий мне сервер.
Вот-вот, за все надо платить :) Вы полагаете, что участием в этом форуме, в этой ветке, выкручиваете MS руки и вот теперь-то он исправится ? :))
Лучше про проблемы MSSQL говорить на соответствующем форуме, IMHO, пользы больше будет.

C уважением.
10 окт 05, 15:32    [1954567]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

ChA wrote:
> locky
> Но согласитесь, truncate завсегда быстрее чем Delete. йето раз.
>
> Безусловно, но физически это несколько разные процессы, не находите ?
> Заменить одно на другое даже на системном уровне не так-то просто...
дык никто и не просит менять, на системном уровне!!!!
если предположить, что у меня всего 1 (прописью: один) коннект, то я
могу юзать обычную табличку, так ведь? Могу делать ей truncate, который
быстрее delete. Так? покак никакого криминала. Теперь у меня 2 коннекта.
Так вот сайбейс каждому коннекту отдает его личную табличку.

> locky
> Когда имеем относительно небольшую вначале табличку, запросто можно
> нарваться на то, что менеджер блокировок заблокирует её всю (так
> дешевле), и остальные процессы будут ждать. Видено неоднократно.
>
> Не сталкивался, хотя и пользую нечто подобное. Только большой она вообще
> никогда не становится :) Почему такое происходит у Вас, ума не приложу,
> надо смотреть. Может хинтами попробовать ? Может посмотреть в сторону
> sp_indexoption ? Все ли там нормально ? READPAST пользовать почаще, так
> как "чужие" записи Вам не нужны, да мало ли...
У нас тоже редко становится большой. Но на определенном моменте SQL
решает, что раз уж блокировано 80% записей (т.е. 80 из 100) то проще
наложить лок на табличку...
Тем паче, у меня не readpast , а nolock.....

> locky
> Да причем тут олап, прости господи, что-ж вы его кругом все тулите.
> Понимаю, слово красивое и направление модное. Но посчитать сальдовку по
> 500К+ счетам это не поможет, не правда-ли?
>
> Этому слову 100 лет в обед :) Простите, но не уверен, что "сальдовку по
> 500К+ счетам" надо делать непременно на весьма активной OLTP, а потом
> удивляться, что это у нас все тормозит. Не говоря уж о том, что
> наверняка это нечастая операция, и, более чем наверняка, ее можно
> посчитать в другое время. Или хранить посчитанные данные заранее, и в
> нужный добавлять только неучтенное.
да знаю я, редко считается... и сводные данные в различных разрезах
считаются джобами по ночам. но есть к сожалению некоторые виды отчетов,
для которых сводные данные сопоставимы по объему с исходными. Тут свод
не сосчитаешь. Кроме того, требуется ведь не только чтобы система 90%
времени работала хорошо, но и то, чтобы в те 10% времени система
работала нормально.

> Log-shipping на другой сервер, наконец, пусть там считают. Да мало ли
> способов...
Другой сервер надо иметь, а это - деньги.

> Вы всерьез полагаете, что на любой из других СУБД "сальдовка по 500К+
> счетам" будет "летать" ?
На сайбейсе - возможно, за счет отказа от логгирования, за счет
сессионных временных таблиц.

>
> locky
> для того чтобы разносить всё на разное железо - на
> железо надо денюжки, и немалые подчас. с другой стороны, в некоторых
> продуктах (не будем тыкать пальцами) эти проблемы решаеются бесплатно
> путем изменения настроек.
> И потом... "Делайте хоть что нибудь!" Дык делаем, работа то должна
> работать, какие бы проблемы у меня лично не возникали, не правда ли?
> Просто хочется проще как-то, душевнее...
>
> Желание получить дешевше, да числом поболе, вполне понятно, но неужели
> Вы верите в чудесную опцию, которую установив, сразу получишь ракету ?
> Если даже так, то почему она сразу не установлена ? По приколу, чтобы
> админу было чем заняться на досуге ? В чудеса-то верить не поздно,
> возраст-то поди уже не тот ? :)
Почему не установлена? не знаю. Тот же сайбес (во прилип), оракл,
информикс - имеют нелогируемы таблицы/базы ( с теми или иными
ограничениями). Значит, пользу от этого понимаю не только я.

>
> locky
> Перейти на чо-нить другое? Ну, знаю их куда хуже (знаю что они есть, но
> как с йими работать...), потом, у них и своих проблем валом, если не
> сказать больше... у меня ведь цель - не сбежать или охаять, а получить в
> MS как можно более подходящий мне сервер.
>
> Вот-вот, за все надо платить :) Вы полагаете, что участием в этом
> форуме, в этой ветке, выкручиваете MS руки и вот теперь-то он исправится
> ? :))
> Лучше про проблемы MSSQL говорить на соответствующем форуме, IMHO,
> пользы больше будет.
Ну, в форуме... там это несколько бессмыслено, там обсуждается как есть,
а не как хочется... А писать письма с пожеланиями... усталь уже...

--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

10 окт 05, 16:16    [1954831]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
C#
Guest
Gluk (Kazan)
Dooma
В конечном результате имеем тот же EXE-шник в машинных кодах, выполнение которого не подходит под определение интерпретатора. Больше подходит на определение компилятора из IL.


Извините, Вы внутрь этого "EXE-ника" заглядывали. Не верите мне, поверьте Рихтеру ссылку на которого я привел чуть выше. Там галимый IL-код ничего общего с машинным не имеющий. Точно также как и в class-файлах.

На заборе тоже не дрова написано, если файл имеет PE-хидер это еще не гарантия того, что внутри машинный код

Там нет машинного кода. Машинный код получается перед первым исполнением. По аналогии с JIT
Но назвать это интерпретатором не верно.
Возможно, правильно будет двухступенчатый компилятор. В смысле не пошаговй, как интерпретатор.
10 окт 05, 16:23    [1954866]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
C#

Там нет машинного кода. Машинный код получается перед первым исполнением. По аналогии с JIT

при желании можно заранее откомпилировать, и сохранить на диске в откомпилированном виде, тогда компиляция при первом исполнении уже будет не нужна
10 окт 05, 16:26    [1954885]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
StalkerS
C#

Там нет машинного кода. Машинный код получается перед первым исполнением. По аналогии с JIT

при желании можно заранее откомпилировать, и сохранить на диске в откомпилированном виде, тогда компиляция при первом исполнении уже будет не нужна


С этого места поподробней
10 окт 05, 16:29    [1954893]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
locky

Но на определенном моменте SQL
решает, что раз уж блокировано 80% записей (т.е. 80 из 100) то проще
наложить лок на табличку...

эсколацию вообще можно отключить, если не нравиться. А в одной из статей Мерле писал, как заставить сервер не применять эсколацию к отдельно взятой таблице
10 окт 05, 16:33    [1954916]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
ЛП
Guest
Gluk (Kazan)
StalkerS
C#

Там нет машинного кода. Машинный код получается перед первым исполнением. По аналогии с JIT

при желании можно заранее откомпилировать, и сохранить на диске в откомпилированном виде, тогда компиляция при первом исполнении уже будет не нужна


С этого места поподробней

Да у того же Рихтера про это упомянуто. Если интересно - могу номер страницы сказать.
10 окт 05, 16:35    [1954923]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
Gluk (Kazan)

С этого места поподробней

Существует утилита NGen.exe. Вот тутпочитать можно. Я правда, не пользовался
10 окт 05, 16:37    [1954937]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
hvlad
Guest
Gluk (Kazan)
Строго говоря, языки платформы .Net, за исключением C++ НЕ КОМПИЛЯТОРЫ
Строго говоря - языкам пох как тексты, написанные на них, обрабатываются дальше - компилятором, интерпретатором или даже архиватором
10 окт 05, 16:39    [1954945]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
StalkerS
locky

Но на определенном моменте SQL
решает, что раз уж блокировано 80% записей (т.е. 80 из 100) то проще
наложить лок на табличку...

эсколацию вообще можно отключить, если не нравиться. А в одной из статей Мерле писал, как заставить сервер не применять эсколацию к отдельно взятой таблице


А чем это закончится для сервера там не написано ???
10 окт 05, 16:43    [1954967]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
StalkerS
Gluk (Kazan)

С этого места поподробней

Существует утилита NGen.exe. Вот тутпочитать можно. Я правда, не пользовался


Ага помню, была такая косточка. Но сути дела это не меняет. C# в частности, стоит в одном ряду с Java и Perl. Мало у кого поворачивается язык называть последние компиляторами, хотя и интерпретаторами х назвать тяжело.

2 hvlad

К сожалению, я не осознал всей глубины Вашего ОЧЕНЬ полезного и уместного замечания относительно того что языкам пох

МНЕ НЕ ПОХ
10 окт 05, 16:48    [1954986]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
>>А чем это закончится для сервера там не написано ???

ничем хорошим. Поэтому эсколация по умолчанию и включена
10 окт 05, 16:52    [1955006]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
hvlad
Guest
Gluk (Kazan)
2 hvlad

К сожалению, я не осознал всей глубины Вашего ОЧЕНЬ полезного и уместного замечания относительно того что языкам пох

МНЕ НЕ ПОХ
А теперь у меня "игривое настроение". Более того - я действительно вижу, что здесь больше прикалываются, чем говорят серьёзно. Т.к. утверждения: "язык - компилятор" и "язык - интерпретатор" одинаково смешны

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

Могу я также поинтересоваться определением компилятора, которое вы подразумеваете в этой затянувшейся беседе ?

Как обычно - ничего личного
10 окт 05, 17:09    [1955108]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Dooma
Guest
Gluk (Kazan)
Ага помню, была такая косточка. Но сути дела это не меняет. C# в частности, стоит в одном ряду с Java и Perl. Мало у кого поворачивается язык называть последние компиляторами, хотя и интерпретаторами х назвать тяжело.

МНЕ НЕ ПОХ
При работе через JIT это очень даже компиляторы. Политкоректнее их называть языками нового поколения.

Мне то же не пох. Тем более, что программы написанные на C# работают как минимум не медленнее аналогичных на Delphi.
10 окт 05, 17:25    [1955186]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
автор
А теперь у меня "игривое настроение".


Ага, точно. Мстя меня настигла !!! Дон поражен в пятку.
Разумеется я имел в виду РЕАЛИЗАЦИИ языков :) Но между нами, не предтставляю кому придет в голову реализовывать С# как компилятор. Что касается Perl-а его просто НЕЛЬЗЯ реализовать как компилятор не убив при этом значительную часть функционала.

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

Как только появится IL-процессор в виде физического девайса, я немедленно признаю, что таки да C# - компилятор
10 окт 05, 17:28    [1955201]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Dooma
Мне то же не пох. Тем более, что программы написанные на C# работают как минимум не медленнее аналогичных на Delphi.


Не стоит быть столь категоричным Как минимум в Delphi отсутствует сборка мусора.

для hvlad

Под Delphi я понимаю одноименный инструментарий Borland до 7-ой версии включительно
10 окт 05, 17:31    [1955222]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

StalkerS wrote:
> locky
>
> Но на определенном моменте SQL
> решает, что раз уж блокировано 80% записей (т.е. 80 из 100) то проще
> наложить лок на табличку...
>
>
> эсколацию вообще можно отключить, если не нравиться. А в одной из статей
> Мерле писал, как заставить сервер не применять эсколацию к /отдельно
> взятой таблице/
мне не надо её отключать, мне надо бы ею управлять...
если, к примеру, мне надо наложить лок на 80% таблицы (800К из 1М) - то
ради бога, пусть будет эскалация. А вот 80 из 100 - плиз, не надо...
зы знаю и как включать/выключать, и всё такое...

--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

10 окт 05, 17:31    [1955224]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
hvlad
Guest
Gluk (Kazan)
автор
А теперь у меня "игривое настроение".


Ага, точно. Мстя меня настигла !!! Дон поражен в пятку
Ну, не совсем мстя...

Gluk (Kazan)
Разумеется я имел в виду РЕАЛИЗАЦИИ языков :) Но между нами, не предтставляю кому придет в голову реализовывать С# как компилятор. Что касается Perl-а его просто НЕЛЬЗЯ реализовать как компилятор не убив при этом значительную часть функционала.

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

Как только появится IL-процессор в виде физического девайса, я немедленно признаю, что таки да C# - компилятор
Всё это (деление на компиляторы и интерпретаторы) очень и очень условно. С точки зрения процессора т.н. машинный код - тоже интерпретируемая программа. У процессоров свой "машинный язык", выполняемый ими непосредственно. Да и сам процессор тоже состоит из конечного числа элементарных логических блоков (И, ИЛИ, НЕ), так штааа... ;) Впрочем - всё это и так известные и очевидные вещи.
Так что иногда не мешает оглянуться назад (с 13-ой страницы) и спросить - 'а был ли мальчик ?', т.е. - о чём спорим-то ?

PS Существует множество железных java-процесоров, применяемых в самых разных устройствах. Если IL кому-нибудь придёт в голову встроить в кофеварку - появятся такие железки и для него :) Не в этом суть...


Gluk (Kazan)
Под Delphi я понимаю одноименный инструментарий Borland до 7-ой версии включительно
Дельфи - это среда разработки. Есть уже 9 версий, 10-я на подходе, так что - определитесь с версиями ;)
А язык называется object pascal, по крайней мере в Борланде употребляют это название
А сборку мусора можно и в Дельфи сделать - было бы зачем :)
10 окт 05, 17:40    [1955282]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
DarkSquid
Member

Откуда: http://terredesreves.3bb.ru/
Сообщений: 4882
Gluk (Kazan)
Не стоит быть столь категоричным Как минимум в Delphi отсутствует сборка мусора.


Зато необхожимость освобождения памяти не исчезает. Память освобождается обычно всегда, когда она становится ненужной. Поэтому, если не задумываться об оптимальной стратегии выделения и освобождения ресурсов, можно легко написать неэффективное приложение, которое будет постоянно то требовать маленькие кусочки памяти, то освобождать их обратно.
10 окт 05, 17:40    [1955283]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
DarkSquid
Member

Откуда: http://terredesreves.3bb.ru/
Сообщений: 4882
Вот написал пост предыдущий - и понял, что не знаю как в C#, а в Java на стеке объект разместить не удастся. А ведь выделение памяти на стеке - самый быстрый способ.
10 окт 05, 17:46    [1955309]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
наболело

А про 7-ку я специяльно уточнил. Все начиная с 8-ки это не Delphi, а .Net-овский отстой

2 hvlad

Оглянуться назад, энто всегда пжалуста. Кое-кто пытался тут уверять что после перевода на .Net бизнес логика Юкона, заработает очччень быстро. Я ответил, что так не считаю и объяснил почему.

Попутно я упомянул, что языки .Net-а кроме C++ это не совсем компиляторы
10 окт 05, 17:47    [1955316]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
DarkSquid
Вот написал пост предыдущий - и понял, что не знаю как в C#, а в Java на стеке объект разместить не удастся. А ведь выделение памяти на стеке - самый быстрый способ.


В C# ТИП объекта определяет где он будет размещен на стеке или в куче.
Тоже маразм на мой взгляд.
10 окт 05, 17:48    [1955324]     Ответить | Цитировать Сообщить модератору
 Re: Yukon почти не виден  [new]
Dooma
Guest
Gluk (Kazan)
Оглянуться назад, энто всегда пжалуста. Кое-кто пытался тут уверять что после перевода на .Net бизнес логика Юкона, заработает очччень быстро. Я ответил, что так не считаю и объяснил почему.
Еще раз вам вопрос, почему?
На момент исполнения этого тригера, ХП,... это будет уже откомпилированный код (если хотите отJIT-ированный код). Так почему же вы так не считаете?
10 окт 05, 17:57    [1955359]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 12 [13] 14 15   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить