Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
 Re: Обоснование выбора СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
pkarklin
Apex
Вы уж определитесь, уважаемый: отсоединенный файл в консистентном состоянии или нет?


Не может бд в MS SQL состоять из одного файла! Понятие консистентность применимо к паре файлов - данные и лог.

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

Apex
Судя по тому, что Вы сказали ранее, то нет (или как минимум не хватает нескольких транзакций, зафиксированных после чекпоинта)


Они в логе, и будут применены при следующем чекпоинте.

Это очевидно. Я имел в виду, что если мы отсоединяем файл данных, то несброшеная информация (а точнее информация для восстановления) находится в логе. Т.е. перед отсоединением не происходит сброс грязных страниц в файл и поэтому требуется лог для переноса на другу БД и поэтому при присоединении из него надо восстановить эти данные, иначе первый же запрос этих данных вернет непонятно что.

pkarklin

Apex
и для его присоединения необходим лог, из которого потом надо донакатить\откатить изменения не попавшие в файл (он же мгновенно отсоедняется).


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

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

pkarklin

Apex
"вырубленную на ходу" - нормальный такой термин, я его например понял.


"вырубленную на ходу" - это когда шнур питания из сервака выдернули - в моем понятии.

Можно просто размонтировать файловую систему, эффект будет тот же, что и при отключении питания.
22 ноя 07, 14:16    [4950228]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
pkarklin

Йес... Круче. Позвольте поинтересоваться, а сколько процентов инсталляций используют сколько функционала Oracle? У мну вот тоже Word стоит, дык я его для печати заявления на отпуск использую, хотя хватило бы и Блокнота, а может то (Word) О-ГО-ГО.

Впрочем как и с большим числом типов индексов. На мой вопрос "а кто практически использовал из этой кучи и сколько типов одновременно и почему было "так много" ответов.

ИМХО, в Ваших рассуждениях есть логическая брешь. Кто сказал, что все возможности, которыми обладает современная РСУБД были сделаны, потому что они все потребовались в один момент? Если в базе одинаково распространены все типы индексов, все способы хранения и они при этом действительно все нужны, то это очень странная и редкая задача...
Как правило верндоры берут курс на универсальность, чтобы один и тот же продукт удовлетворил потребности заказчика в различных ситуациях.
22 ноя 07, 14:23    [4950284]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
locky
Member

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

Apex wrote:
> Как правило верндоры берут курс на универсальность, чтобы один и тот же
Спорный утверждений.
Обычно курс берется не на "универсальность".
"Универсальность" - денег не стоит.
Денег стоит - надежность, производительность....

Posted via ActualForum NNTP Server 1.4

22 ноя 07, 14:26    [4950316]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Apex
Вот именно этого ответа я и добивался. Значит лог все-таки нужен,


По-моему, я это ни один раз это повторил.

Apex
значит файл данных надо (позвольте мне использовать этот привычный для меня термин) воостановить при аттаче из лога. Правильно?


Apex
Это очевидно.


Т.е. перед отсоединением не происходит чекпоинт и поэтому требуется лог для переноса на другу БД

Apex
и поэтому при присоединении из него надо восстановить эти данные, иначе первый же запрос этих данных вернет непонятно что.


Если Вы присоедините бд без лога, то запрос вернет данные, которые были на момент отсоединения в файле данных.

Вы все так упорно бъете на неконсистентность, что можно подумать, что в файле данных пол транзакции может оказаться.


Apex
В этом случае файл данных отсоединяется так же, без сброса грязных страниц в файл?


В каком "в этом"?! Отсодение всегда происходит единообразно. На то, как Вы будете присоединять бд полностью или без лога (ну поетряли мы его и хочется хоть большую часть данных поиметь) никак на влияет на то, как Вы ее отсоединили. Результаты присоединения могут быть разными.
22 ноя 07, 14:27    [4950329]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Apex
Как правило верндоры берут курс на универсальность, чтобы один и тот же продукт удовлетворил потребности заказчика в различных ситуациях.


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

Ну и что, у Оракла в редакции за 5 000 баксов на процессор есть, туева хуча типов индексов? Зато за ту же цену в MS SQL вы получите и OLAP и Reporting и т.п.
22 ноя 07, 14:35    [4950389]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
pkarklin

В каком "в этом"?! Отсодение всегда происходит единообразно. На то, как Вы будете присоединять бд полностью или без лога (ну поетряли мы его и хочется хоть большую часть данных поиметь) никак на влияет на то, как Вы ее отсоединили. Результаты присоединения могут быть разными.

Все, я просто не понимал как происходит отсоедниение в MS SQL.

pkarklin
Если Вы присоедините бд без лога, то запрос вернет данные, которые были на момент отсоединения в файле данных.

Вы все так упорно бъете на неконсистентность, что можно подумать, что в файле данных пол транзакции может оказаться.

Замечательная, должен сказать, вырисовывается картина... Т.е. в файле могут оказаться данные, которые были зафиксированы не на момент отсоедниения (непосредственно когда я выдал команду на детач) а в какой-то произвольный(?) момент времени в прошлом, который зависит от многих факторов. Т.е. в этом случае мне нужен лог, из которого все-таки придется донакатываться вопреки сказанному Вами ранее
pkarklin
Аттач ни чего не восстанавливает, ибо восстанавливать нечего.

Или же нет и мы все время будем получать из файла "старые данные", даже если есть лог? Я вообще запутался уже:(

Ну даже это меня не столько удивило, сколько то, что из Ваших слов следует, что при чекпоинте MS SQL сбрасывает в файл только зафиксированные данные! Это правда?
22 ноя 07, 15:19    [4950794]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
pkarklin

Ну и что, у Оракла в редакции за 5 000 баксов на процессор есть, туева хуча типов индексов? Зато за ту же цену в MS SQL вы получите и OLAP и Reporting и т.п.

Дались Вам эти индексы, индексов там в самой дорого редакции только 4 вида: B-tree, bitmap, fb, media. Больше не помню...
22 ноя 07, 15:23    [4950836]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Yo.!
Guest
2pkarklin

разачарован, скатились до уровня фанов MySQL времен 3.х, которые кричали, у нас тразакций нет и нах они нужны. большая часть населения земли не знает, что такое канализация, чего теперь все будем срать в выгребные ямы и пить тухлую воду !?
то что дает оракл за $5K за проц, ГОРАЗДО навороченей EE редакции MS в том числе и за счет туевой кучи индексов (в SE нет только bitmap index).

2Apex

Type of index Oracle Database 10g/SQL Server 2005
B-tree indexes Yes / Yes
B-tree cluster indexes Yes / No
Hash cluster indexes Yes / No
Reverse key indexes Yes / No
Bitmap indexes Yes / No
Bitmap join indexes Yes / No
Function-based indexes Yes / No
Domain indexes Yes / No
Index-organized tables Yes / Yes (clustered indexes)
22 ноя 07, 15:34    [4950910]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
А6дулла
Member [заблокирован]

Откуда: эврибади нид Someбади
Сообщений: 1733
Yo, вы сравниваете субды как типичный упертый технарь, не беря в расчет стоимость владения!
И выход полезной работы на один человеко-час!

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

p.s.
Function-based indexes Yes / Yes (computed column + index)
22 ноя 07, 15:44    [4950986]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Yo.!
Guest
А6дулла
Yo, вы сравниваете субды как типичный упертый технарь, не беря в расчет стоимость владения!
И выход полезной работы на один человеко-час!

почему вы так решили ? я все учитываю, просто задумайтесь какая производительность будет у майкрософтского девелопера если он вынужден писать на сильно ущербном t-sql где нет элементарных вещей типа пакетов, рекурсий, ref_cursor и вынужден изобретать велосипеды типа materialized view, autonomous transactions т.д. и т.п.
то же самое с дба, оракловый дба имеет просто на порядок внушительней инструменты в виде скриптов rman, flashback, отслеживания зависимостей и т.п. это все есть в 2 days dba и сильно экономит время, а значит и стоимость администрирования.
22 ноя 07, 16:01    [4951112]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Apex
Т.е. в файле могут оказаться данные, которые были зафиксированы не на момент отсоедниения (непосредственно когда я выдал команду на детач) а в какой-то произвольный(?) момент времени в прошлом, который зависит от многих факторов.


Для продолжения разговора стоит придерживаться терминологии обсуждаемого продукта. О каком файле Вы говорите? Что и где было зафиксировано? В какой момент?

Apex
Т.е. в этом случае мне нужен лог, из которого все-таки придется донакатываться вопреки сказанному Вами ранее


О том, что происходит после присоединения, я, как мне казалось, уже писАл.

Apex
Ну даже это меня не столько удивило, сколько то, что из Ваших слов следует, что при чекпоинте MS SQL сбрасывает в файл только зафиксированные данные! Это правда?


Если не прошел коммит или ролбэк (транзакция не зафиксирована), то она есть только в логе.
22 ноя 07, 16:03    [4951127]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
разачарован, скатились до уровня фанов MySQL времен 3.х, которые кричали, у нас тразакций нет и нах они нужны.


Да не стоит разочарований. Не все же мне только техническими деталями "прикрываться". ;)Я подтвердил, что Oracle круче (можно подумать, что я с этим когда-то спорил).

Yo.!
большая часть населения земли не знает, что такое канализация, чего теперь все будем срать в выгребные ямы и пить тухлую воду !?


Большая часть населения пользуется канализацией из труб в 1 000 мм диаметром. Для того, чтобы посрать городу из 150 тыс. населения, совсем не обязательно строить канализаци, по которой на грузовике можно ездить.

Yo.!
то что дает оракл за $5K за проц, ГОРАЗДО навороченей EE редакции MS в том числе и за счет туевой кучи индексов (в SE нет только bitmap index).


OLAP есть в SE? А репортинг какой-нибудь?
22 ноя 07, 16:12    [4951221]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
я все учитываю, просто задумайтесь какая производительность будет у майкрософтского девелопера если он вынужден писать на сильно ущербном t-sql где нет элементарных вещей типа пакетов, рекурсий, ref_cursor и вынужден изобретать велосипеды типа materialized view, autonomous transactions т.д. и т.п


Ну, не стоит в другую крайность то бросаться. ;) Каким образом наличиче пакетов сможет поднять производительность?

Yo.!
ref_cursor


Зачем он мне?!

автор
materialized view


Все уже давно изобретено - indexed views.

Yo.!
]autonomous transactions


Нет их. Нет. в 958 раз повторяю, что их нет.
22 ноя 07, 16:16    [4951273]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472

> 958 раз повторяю
забей, а?


Posted via ActualForum NNTP Server 1.4

22 ноя 07, 16:25    [4951365]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Yo.!
Guest
pkarklin

Ну, не стоит в другую крайность то бросаться. ;) Каким образом наличиче пакетов сможет поднять производительность?

примерно тем же, чем продуманая система папок проэкта помогает против сваленой_в_кучу_хп_с очень_длинными_именнами + сокращает кол-во кода, не нужно в каждой хп заново объявлять одни и теже курсоры, переменные, для дба сильно упрощается упрвление правами.

pkarklin

Yo.!
ref_cursor

Зачем он мне?!

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

pkarklin

автор
materialized view

Все уже давно изобретено - indexed views.

слабое подобие левой руки, min, max, count элементарных вещей не умеет.

pkarklin

Yo.!
]autonomous transactions

Нет их. Нет. в 958 раз повторяю, что их нет.

1058 раз повторяю, что знаю. потому и говорю что каждый раз наблюдая изобретенный велосипед логирования в mssql удивляюсь на какую хрень девелоперы тратят столько усилий. если взять зарплату обычного девелопера в $1.5K - $2K, что с налогами канторе выходит уже все $3K-$4K, то стоимость этих вынужденых извратов и велосипедов, легко может компенсировать не только SE one, но и $40K+опции за EE редакцию
22 ноя 07, 16:47    [4951552]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Apex
pkarklin

В каком "в этом"?! Отсодение всегда происходит единообразно. На то, как Вы будете присоединять бд полностью или без лога (ну поетряли мы его и хочется хоть большую часть данных поиметь) никак на влияет на то, как Вы ее отсоединили. Результаты присоединения могут быть разными.

Все, я просто не понимал как происходит отсоедниение в MS SQL.

pkarklin
Если Вы присоедините бд без лога, то запрос вернет данные, которые были на момент отсоединения в файле данных.

Вы все так упорно бъете на неконсистентность, что можно подумать, что в файле данных пол транзакции может оказаться.

Замечательная, должен сказать, вырисовывается картина... Т.е. в файле могут оказаться данные, которые были зафиксированы не на момент отсоедниения (непосредственно когда я выдал команду на детач) а в какой-то произвольный(?) момент времени в прошлом, который зависит от многих факторов. Т.е. в этом случае мне нужен лог, из которого все-таки придется донакатываться вопреки сказанному Вами ранее
pkarklin
Аттач ни чего не восстанавливает, ибо восстанавливать нечего.

Или же нет и мы все время будем получать из файла "старые данные", даже если есть лог? Я вообще запутался уже:(

Ну даже это меня не столько удивило, сколько то, что из Ваших слов следует, что при чекпоинте MS SQL сбрасывает в файл только зафиксированные данные! Это правда?

Что принципиально меняется от того что вместо одного файла надо иметь два(данные и лог)?



Синтаксис

sp_attach_db [ @dbname= ] 'dbname' , [ @filename1= ] 'filename_n' [ ,...16 ]
[ @dbname= ] ' dbname '
Имя базы данных, присоединяемой к серверу. Имя должно быть уникальным. Аргумент dbname имеет тип sysname и значение NULL по умолчанию.

[ @filename1= ] ' filename_n '
Физическое имя файла базы данных вместе с путем. Аргумент filename_n имеет тип nvarchar(260) и значение NULL по умолчанию. Можно указать до 16 имен файлов. Имена аргументов начинаются с @filename1 и возрастают до @filename16. Список имен файлов должен включать хотя бы первичный файл. Первичный файл содержит системные таблицы, указывающие на другие файлы базы данных. Список также должен включать все файлы, перемещенные после отключения базы данных.






sp_detach_db [ @dbname= ] 'dbname' [ , [ @skipchecks= ] 'skipchecks' ] [ , [ @KeepFulltextIndexFile= ] 'KeepFulltextIndexFile' ]

[ @skipchecks = ] 'skipchecks'
Указывает, запускать или нет UPDATE STATISTIC. Аргумент skipchecks имеет тип nvarchar(10) и значение по умолчанию NULL. Чтобы не запускать UPDATE STATISTICS, укажите true. Чтобы явно запустить UPDATE STATISTICS, укажите false.

По умолчанию UPDATE STATISTICS запускается для обновления информации о данных в таблицах и индексах в компоненте Microsoft SQL Server 2005 Database Engine. Выполнение UPDATE STATISTICS имеет смысл для тех баз данных, которые планируется переместить на постоянные носители информации.
22 ноя 07, 16:59    [4951653]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
locky
Member

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

Yo.! wrote:
> примерно тем же, чем продуманая система папок проэкта помогает против
> сваленой_в_кучу_хп_с очень_длинными_именнами + сокращает кол-во кода, не
Вот и сами ответили на свой вопрос....
VS+TFS - спасает отца русской демократии...

Posted via ActualForum NNTP Server 1.4

22 ноя 07, 17:08    [4951741]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
примерно тем же, чем продуманая система папок проэкта помогает против сваленой_в_кучу_хп_с очень_длинными_именнами


Какая разница как свалены объекты на сервере?! Разложите их исходникик по папочкам в любом VCS.

Yo.!
сокращает кол-во кода, не нужно в каждой хп заново объявлять одни и теже курсоры, переменные, для дба сильно упрощается упрвление правами.


Из-за отсуттсвия пакетов T-SQL не становится мене модульным. Глабольные переменные и курсоры на уровне пакета - фи... моветон...

Yo.!
эээ ... мне не понятно как без них


Вот так например:

USE AdventureWorks;
GO
IF OBJECT_ID ( 'dbo.uspCurrencyCursor', 'P' ) IS NOT NULL
    DROP PROCEDURE dbo.uspCurrencyCursor;
GO
CREATE PROCEDURE dbo.uspCurrencyCursor 
    @CurrencyCursor1 CURSOR VARYING OUTPUT,
    @CurrencyCursor2 CURSOR VARYING OUTPUT
AS
    SET @CurrencyCursor1 = CURSOR
    FORWARD_ONLY STATIC FOR
      SELECT CurrencyCode, Name
      FROM Sales.Currency;
    OPEN @CurrencyCursor1;
    SET @CurrencyCursor2 = CURSOR
    FORWARD_ONLY STATIC FOR
      SELECT CurrencyCode, Name
      FROM Sales.Currency;
    OPEN @CurrencyCursor2;

GO


DECLARE
  @CurrencyCursor1 CURSOR,
  @CurrencyCursor2 CURSOR

EXEC dbo.uspCurrencyCursor 
    @CurrencyCursor1 = @CurrencyCursor1 OUTPUT,
    @CurrencyCursor2 = @CurrencyCursor2 OUTPUT

FETCH NEXT FROM @CurrencyCursor1
FETCH NEXT FROM @CurrencyCursor1

FETCH NEXT FROM @CurrencyCursor2

FETCH NEXT FROM @CurrencyCursor1

CLOSE @CurrencyCursor1 
CLOSE @CurrencyCursor2

DEALLOCATE @CurrencyCursor1 
DEALLOCATE @CurrencyCursor2

Еще бы. Реализация временных таблиц в Oracle "слаба". :) То, что сделате разработчик на сиквеле реляционным подходом с использованием временной таблицы (табличной переменной), разарботчик оракле будет городить рефкурсор.

Yo.!
слабое подобие левой руки, min, max, count элементарных вещей не умеет.


Просто для чего-то более "cильного" используют OLAP. У Оракле, даже в ЕЕ его нет. Выкладывайте дополнительные бабосы. Аналитикам глубоко наплевать на:

Yo.!
B-tree indexes Yes / Yes
B-tree cluster indexes Yes / No
Hash cluster indexes Yes / No
Reverse key indexes Yes / No
Bitmap indexes Yes / No
Bitmap join indexes Yes / No
Function-based indexes Yes / No
Domain indexes Yes / No
Index-organized tables Yes / Yes (clustered indexes)


а вот кубики им очень нравяться. так же как и отчетики.

Yo.!
если взять зарплату обычного девелопера в $1.5K - $2K, что с налогами канторе выходит уже все $3K-$4K, то стоимость этих вынужденых извратов и велосипедов, легко может компенсировать не только SE one, но и $40K+опции за EE редакцию


Посмешили...
22 ноя 07, 17:20    [4951828]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
pkarklin
andsm
Перед отсоединением БД в ней происходит чекпойнт.


Нет.

Можно проверить так это или нет с использованием трейс-флага 3502, который отображает чекпойнты в логе сервера
22 ноя 07, 19:14    [4952497]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
JetAlex
Member

Откуда:
Сообщений: 84
А мне кажется, многое зависит просто от класса задачи и того, сколько за систему готов заплатить клиент.
Для нас лучше всего оказалася Sybase Adaptive Server Anywhere.
ОЧень не догрогой и компактный. Не требует никаго администрирования со стороны конечного клиента и очень надежный
22 ноя 07, 19:23    [4952536]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472

>Для нас лучше всего оказалася Sybase Adaptive Server Anywhere.
>ОЧень не догрогой и компактный. Не требует никаго администрирования
Oracle XE. 200 метров инсталяха, полгода никто в него не заглядывал.
крутится себе


Posted via ActualForum NNTP Server 1.4

23 ноя 07, 08:20    [4953376]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
SergSuper
Что принципиально меняется от того что вместо одного файла надо иметь два(данные и лог)?

Ничего. С моей стороны никаких претензий, я просто хочу понять как это работает, а то господин pkarklin меня окончательно запутал. Господа, не сочтите за труд, дайте пожалуйста ссылку на описание механики данного процесса.
-------------------------------------------------------
Автор благодарит алфавит за любезно предоставленные ему буквы.
23 ноя 07, 09:46    [4953584]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Apex
а то господин pkarklin меня окончательно запутал.


Что конкретно Вы хотите знать?

Apex
дайте пожалуйста ссылку на описание механики данного процесса.


Сам механизм отсоединения\присоединения не документирован.
23 ноя 07, 10:51    [4953933]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
pkarklin

Что конкретно Вы хотите знать?

1) Происходит ли накат изменений из лога, если мы переносим базу (пара - файл + лог)? Если нет, то почему?
2) Учитывая
pkarklin
Существует возможность присоединить файл данных и без файла лога (в случаи если он недоступен)

и
pkarklin
Если Вы присоедините бд без лога, то запрос вернет данные, которые были на момент отсоединения в файле данных.

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

P.S.
pkarklin
Понятие консистентность применимо к паре файлов - данные и лог.

Нет, в оракле я могу переносить файлы данных без лога. Уверен, что если правильно остановить MS SQL, то лог для открытия тоже не понадобится.
23 ноя 07, 11:30    [4954170]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Я
1) Происходит ли накат изменений из лога, если мы переносим базу (пара - файл + лог)? Если нет, то почему?

Поправка: Происходит ли накат изменений из лога при подключении базы...
-------------------------------------------------------
Автор благодарит алфавит за любезно предоставленные ему буквы.
23 ноя 07, 11:32    [4954182]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить