powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Yukon почти не виден
25 сообщений из 359, страница 13 из 15
Yukon почти не виден
    #33315304
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexey_tm StalkerS alexey_tm
А он просто выделяет памаять по максимуму и больше ее не трогает.

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

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


Просмотрел форумы с Вашим участием, удручает... И вызывают сомнения Ваши заявления.
Оцениваете уровень моего интеллекта, вместо того, чтобы почитать хотя-бы BOL ? ну-ну, продолжайте в том-же духе...
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315326
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DoomaВ конечном результате имеем тот же EXE-шник в машинных кодах, выполнение которого не подходит под определение интерпретатора. Больше подходит на определение компилятора из IL.

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

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

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

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

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

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

C уважением.
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315506
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315527
C#
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
C#
Гость
Gluk (Kazan) DoomaВ конечном результате имеем тот же EXE-шник в машинных кодах, выполнение которого не подходит под определение интерпретатора. Больше подходит на определение компилятора из IL.

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

На заборе тоже не дрова написано, если файл имеет PE-хидер это еще не гарантия того, что внутри машинный код
Там нет машинного кода. Машинный код получается перед первым исполнением. По аналогии с JIT
Но назвать это интерпретатором не верно.
Возможно, правильно будет двухступенчатый компилятор. В смысле не пошаговй, как интерпретатор.
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315538
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
C#
Там нет машинного кода. Машинный код получается перед первым исполнением. По аналогии с JIT

при желании можно заранее откомпилировать, и сохранить на диске в откомпилированном виде, тогда компиляция при первом исполнении уже будет не нужна
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315544
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerS C#
Там нет машинного кода. Машинный код получается перед первым исполнением. По аналогии с JIT

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

С этого места поподробней
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315558
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
locky
Но на определенном моменте SQL
решает, что раз уж блокировано 80% записей (т.е. 80 из 100) то проще
наложить лок на табличку...

эсколацию вообще можно отключить, если не нравиться. А в одной из статей Мерле писал, как заставить сервер не применять эсколацию к отдельно взятой таблице
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315562
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan) StalkerS C#
Там нет машинного кода. Машинный код получается перед первым исполнением. По аналогии с JIT

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

С этого места поподробней
Да у того же Рихтера про это упомянуто. Если интересно - могу номер страницы сказать.
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315569
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)
С этого места поподробней
Существует утилита NGen.exe. Вот тут почитать можно. Я правда, не пользовался
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315573
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Строго говоря, языки платформы .Net, за исключением C++ НЕ КОМПИЛЯТОРЫ Строго говоря - языкам пох как тексты, написанные на них, обрабатываются дальше - компилятором, интерпретатором или даже архиватором
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315584
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerS locky
Но на определенном моменте SQL
решает, что раз уж блокировано 80% записей (т.е. 80 из 100) то проще
наложить лок на табличку...

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

А чем это закончится для сервера там не написано ???
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315597
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerS Gluk (Kazan)
С этого места поподробней
Существует утилита NGen.exe. Вот тут почитать можно. Я правда, не пользовался

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

2 hvlad

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

МНЕ НЕ ПОХ
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315608
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>>А чем это закончится для сервера там не написано ???

ничем хорошим. Поэтому эсколация по умолчанию и включена
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315656
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)2 hvlad

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

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

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

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

Как обычно - ничего личного
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315709
Dooma
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Gluk (Kazan) Ага помню, была такая косточка. Но сути дела это не меняет. C# в частности, стоит в одном ряду с Java и Perl. Мало у кого поворачивается язык называть последние компиляторами, хотя и интерпретаторами х назвать тяжело.

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

Мне то же не пох. Тем более, что программы написанные на C# работают как минимум не медленнее аналогичных на Delphi.
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315720
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторА теперь у меня "игривое настроение".

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

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

Как только появится IL-процессор в виде физического девайса, я немедленно признаю, что таки да C# - компилятор
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315728
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DoomaМне то же не пох. Тем более, что программы написанные на C# работают как минимум не медленнее аналогичных на Delphi.

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

для hvlad

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

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315756
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan) авторА теперь у меня "игривое настроение".

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

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

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

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

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


Gluk (Kazan)Под Delphi я понимаю одноименный инструментарий Borland до 7-ой версии включительно Дельфи - это среда разработки. Есть уже 9 версий, 10-я на подходе, так что - определитесь с версиями ;)
А язык называется object pascal, по крайней мере в Борланде употребляют это название
А сборку мусора можно и в Дельфи сделать - было бы зачем :)
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315757
Фотография DarkSquid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Не стоит быть столь категоричным Как минимум в Delphi отсутствует сборка мусора.


Зато необхожимость освобождения памяти не исчезает. Память освобождается обычно всегда, когда она становится ненужной. Поэтому, если не задумываться об оптимальной стратегии выделения и освобождения ресурсов, можно легко написать неэффективное приложение, которое будет постоянно то требовать маленькие кусочки памяти, то освобождать их обратно.
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315768
Фотография DarkSquid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот написал пост предыдущий - и понял, что не знаю как в C#, а в Java на стеке объект разместить не удастся. А ведь выделение памяти на стеке - самый быстрый способ.
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315769
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
наболело

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

2 hvlad

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

Попутно я упомянул, что языки .Net-а кроме C++ это не совсем компиляторы
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315773
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DarkSquidВот написал пост предыдущий - и понял, что не знаю как в C#, а в Java на стеке объект разместить не удастся. А ведь выделение памяти на стеке - самый быстрый способ.

В C# ТИП объекта определяет где он будет размещен на стеке или в куче.
Тоже маразм на мой взгляд.
...
Рейтинг: 0 / 0
Yukon почти не виден
    #33315786
Dooma
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Gluk (Kazan) Оглянуться назад, энто всегда пжалуста. Кое-кто пытался тут уверять что после перевода на .Net бизнес логика Юкона, заработает очччень быстро. Я ответил, что так не считаю и объяснил почему.
Еще раз вам вопрос, почему?
На момент исполнения этого тригера, ХП,... это будет уже откомпилированный код (если хотите отJIT-ированный код). Так почему же вы так не считаете?
...
Рейтинг: 0 / 0
25 сообщений из 359, страница 13 из 15
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Yukon почти не виден
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]