ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / О ненужных возможностях
17 сообщений из 42, страница 2 из 2
  2  все
О ненужных возможностях
    #32482661
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2All
Давайте всё-ж таки так: журналирование и безопасность - 2 раздельных вопроса. То, что они озвучены в одном сообщении - не 2 же было писать, верно?
2Павел & mir
Угу... двухфазная фиксация... безопасность..
угу... Берём базу статистики (по чему угодно) за прошлые периоды. Для надёжности ставим ей RO (данные то за прошлые периоды всё равно не меняются). Данные испортить не может никто. гарантировано. Значит, журналирование не нужно. Безопасность? Ну, да... читать, теоретически тоже не все могут... Бог с ним, пусть читают все. Зачем тогда нам безопасноть?
Начинаем считать по базе всякие полезные отчеты.
делаем нечто вроде
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
create table #temp(F1 int..... FN int)
insert into #temp(F1,.... FN)
select Sum(I1),...,Sum(IN)
from SomeTable
group by SomeField
select * from #temp
drop table #temp

что происходит? при заполнении таблички #temp в лог пишется: что было и что стало. затем checkpoint переносит это из лога в саму базу. Т.е. Вместо одной операции записи данных я имею 3: Запись "Было" в лог, Запись "Стало" в лог, запись в базу.
Если при выполнении запроса произойдет ошибка - Вам очень будет нужно вернуть табличку #temp в прежнее состояние? Не думаю. Зачем в таком случае мне журналирование? Вроде бы как и ни зачем.
Однако, в случае ошибки пойдет откат, который, кстати, тоже занимает время (причем немало, не меньше, чем было время вставки, но, по моим наблюдениям от 1.5 до 3 раз больше).
Т.е., теоретически (на практике то как это сделаешь?) операции при отключенным журналировании должны быть минимум на 50% быстрее.
Следующее. Если мы всё пишем в лог, в 2-м размере, то и место под этот лог должно быть. Т.е. за ненужную мне возможность я плачу: процессорным временем, временем пользователя, дисковым пространством. Дорого получается.
Далее. В Informix, Oracle и (вроде бы) Sybase есть возможность тем или иным образом отключить журналирование для Таблицы/базы. Следовательно, необходимость в этом возникала и, по всеё видимости, неоднократно.

По поводу отключения безопасности. Произвести замеры возможности нет, т.к. нет возможности отключить систему безопасности. Но, как мне думается, если принять минимально возможные разрешения, то выигрышь от такого отключения действительно будет минималным.
2f_w_P
ну... если Васю охрана пропустит в опечатанную комнату... тогда у него будет доступ к подсети... Я ведь могу изобразить и картинку, где сервер приложений имеет 2 сетевые карты, одна уходит во внешний мир, другая - во внутреннее кольцо с сервером БД и между которыми нет роутинга. По идее.... должно работать.
...
Рейтинг: 0 / 0
15.04.2004, 13:33
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32482710
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
А вы замените пример на такое
Код: plaintext
1.
2.
3.
4.
5.
6.
declare @temp table(F1 int..... FN int)
insert into @temp(F1,.... FN)
select Sum(I1),...,Sum(IN)
from SomeTable
group by SomeField
select * from @temp
--drop table #temp


И никаких логов в tempDB.

ЗЫ Бой с тенью. Есть например Yaffil Embedded - там права не проверяются, даже логин не нужен. :)

-- Tygra's --
...
Рейтинг: 0 / 0
15.04.2004, 14:00
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32482715
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
2 locky

Для r/o данных журналирование (в Oracle) отключается автоматически.
не считайте разработчиков СУБД глупее себя.
...
Рейтинг: 0 / 0
15.04.2004, 14:02
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32482716
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
Кстати для temporary тоже
...
Рейтинг: 0 / 0
15.04.2004, 14:02
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32482955
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Воронцов
Участник
To locky
Тут кто-нибудь утверждал, что 1) журналирование и 2) система безопасности не замедляют работу базы? Вам пытаются сказать. что не в этом счастье, что отключать их - глупо, Вы не туда смотрите. Если сильно хочется, то отключить можно, но в общем случае это глупо. Можете не соглашаться - право ваше.
...
Рейтинг: 0 / 0
15.04.2004, 15:28
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32482961
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2Tygra
Код: plaintext
1.
2.
3.
4.
5.
declare @tab table(id int not null)
insert into @tab(id) values( 0 )
select * from @tab
insert into @tab(id) select  1  union all select null
select * from @tab

после ошибки видим, что не вставился не только null, но и 1, т.е. операция вставки атомарна, при ошибке откатывается, т.е. ведеться журналирование. Это подтверржадется также тем, что table var представляются в иде временных табличек в tempdb. Кроме того, таблички у меня используются для передачи данных из процедуры в процедуру (правда, не временные, а постоянные разделенные по spid).
2Gluk
В MS SQL тоже. Для базы, на которой стоит RO. Но проблема в том, что читаю я из базы RO а пишу в tempdb, для которой журналирование ведеться.
...
Рейтинг: 0 / 0
15.04.2004, 15:30
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32483002
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
В Oracle не ведется, там журналирование отделено от откатов
Журналирование в REDO, откаты в Roolback, Так как операции над временными
данными не подлежат восстановлению, журналирование не ведется.

Прошу не воспринимать это как начала треда "что лучше" MS SQL 2000 я весьма уважаю.
...
Рейтинг: 0 / 0
15.04.2004, 15:51
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32483063
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
авторЭто подтверржадется также тем, что table var представляются в иде временных табличек в tempdb

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

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

-- Tygra's --
...
Рейтинг: 0 / 0
15.04.2004, 16:15
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32483066
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
lockyпосле ошибки видим, что не вставился не только null, но и 1, т.е. операция вставки атомарна, при ошибке откатывается, т.е. ведеться журналирование
А может оно сначала попыталось null вставить, а единица потом шла? ;)
Хотя скорее всего сначала проверяет, а потом вставляет

Я лично считаю что не стоит гоняться за милисекундами и не надо бояться линейной потери производительности - т.е. когда время на потери растёт пропорционально объёму данных(в пределах разумного конечно). Вот когда растёт пропорционально квадрату или еще хуже - тогда да.

А затраты времени на проверку прав - ну это как в анекдоте:
- Сколько стоит Ваш автомобиль?
- С полным баком или без?
...
Рейтинг: 0 / 0
15.04.2004, 16:16
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32483160
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jimmy
Участник
2 locky
Если мне память не изменяет (а может, если не прав - поправьте) разрешения храняться в sysprotects. Индексы есть? Нету? Будем сканить.
Есть на что время потратить? С моей точки зрения, есть. Согласен, данная проверка происходит достаточно быстро. При единичном запросе. Усложним. Запросов стало N. Нет, N мало, пусть M. Умножаем время проверки X на количество запросов M - получаем Z секунд времени, потраченного на НЕНУЖНУЮ мне функциональность.

Похоже, слово "кэширование" ты не слыхал.
Жаль.
На самом деле это - такая технология, которая выступает в роли хирурга, который может помочь плохому танцору...


------------
Best regards, Jimmy
...
Рейтинг: 0 / 0
15.04.2004, 16:52
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32483464
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2Tygra
Предметную область или всё-же инструмент? Инструмент - да, подтверждаю, знаю не досконально, не боюсь в этом признаться.
Если не сложно - дайте ссылку на ветку обсуждения table vars.
2SergSuper
Поставьте order by по вкусу - всё равно не вставляет, да и судя по описаниям не должна.
2Jimmy
Слышал, есть такая штука, кэширование... И что? То, что кто-то может эффективно выполнять ненужную мне работу - меня не радует ни капельки.

2All
Давайте определимся. Есть транзакции на уровне блока операторов. Есть транзакции (неявные) на уровне одного оператора (insert,update,delete)
Меня в некоторых случаях устраивает "транзакция" на уровне страницы, а не оператора. В чем неправильность моего желания?
...
Рейтинг: 0 / 0
15.04.2004, 19:46
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32483646
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
И тем не менее, повторюсь. Все эти рассуждения о "ненужной работе" и о "замедлении" абсолютно не подкреплены какими-либо цифрами. Все на уровне размахивания руками. Вот если бы была конкретная задача, а сервер бы с ней не справлялся, тогда бы стоило искать пути повышения производительности. А ведь путей этих множество, и главные среди них:
1) оптимизация запросов
2) оптимизация структур хранения (возможно, денормализация)
3) upgrade железа
4) смена сервера БД.

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

Так о чем речь-то?
...
Рейтинг: 0 / 0
16.04.2004, 07:49
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32483983
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Вот, панимаешь, почему нельзя отключить у автомобиля тормоза? Ведь мешают, заразы. Разогнался вроде - а тут бац, нажал на педаль и вся скорость псу под хвост. Вот если бы можно было отключать тормоза совсем - вот хорошо то было бы. Не, без тормозов только мне можно - я то ездить умею - обычно по двору ездить зачем тормоза? А пусть остальные с тормозами ездят - но за этим должен пьяный механик следить. Но если он не уследит - это не мои проблемы, мне бы побыстрее, разогнался и никто не остановит

-- Tygra's --
...
Рейтинг: 0 / 0
16.04.2004, 11:38
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32484420
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2Mir
Первый и второй путь я никогда не отвергал и не отвергаю. Всемерно этим пользуюсь и т.д.
3-й путь - дорого, однако. По крайней мере заказчик считает, что дорого. В чем-то я с ним согласен.
4-й путь - не для меня. Можут быть, увы, может быть - к счастью.
Но! Где-то тут потерялся путь - правильная настройка сервера. И очень досадно, что нету в MS SQL такой настроечки, которая есть у других.
Хотя, если положить руку на сердце, мне вполне бы подошла опция типа
Код: plaintext
1.
option(commit every n)

где n - количество строк, после которого надо делать commit
а то приходится делать вот так
Код: plaintext
1.
2.
3.
4.
5.
set rowcount  10000 
while  1 = 1  begin
 delete SomeTable where SomeCondition
 if @@rowcount =  0  break
end
...
Рейтинг: 0 / 0
16.04.2004, 14:48
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32484542
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
www.fun4me.narod.ru
Участник
lockyа то приходится делать вот так
Здорово. А то я через while begin select top во временную таблицу; delete end делал.
...
Рейтинг: 0 / 0
16.04.2004, 15:34
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32487017
Alexander_Chepack
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexander_Chepack
Участник
Для обсуждения влияния журналирования временных таблиц на производительность, неплохо бы (для начала) на реализацию прикладной части посмотреть - а то в 90% случаев, чем яростнее человек борется с архитектурой СУБД, тем больший ужас вызывает просмотр его "творений"...
...
Рейтинг: 0 / 0
19.04.2004, 22:06
| Ответить | Цитировать | Написать  
О ненужных возможностях
    #32487428
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2A. Chepack
Не, что касаемо модичикации данных и всё такое - там у меня претензий ни к скорости ни к журналированию ни практически ни к чему претензий нет. А вот к отчетности... Ну, есть. Ну, могу порешать (и решаю). Но хочется то большего и меньшими усилиями :-(
...
Рейтинг: 0 / 0
20.04.2004, 11:24
| Ответить | Цитировать | Написать  
17 сообщений из 42, страница 2 из 2
  2  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / О ненужных возможностях
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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