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

Откуда: Кишинёв
Сообщений: 6723
invm
Т.е. вы считаете, что нужно иметь две Storage Engine: ту, что есть сейчас и специализированную для табличных переменных? Не перебор?
Кхм. А причём тут ещё один "Storage Engine"?
Скорее упрощение механизмов. Мне кажется вы недопонимаете.
Лог/грязные страницы/... скидывается на диск как-то?! Какой-то внутренней системной "функцией".
И почему вместо её повторного использования, надо повторно использовать высоко-уровневые абстракции типа таблица?
Странно как-то вы рассматриваете программную архитектуру скуля. Я рассматриваю некоторые решения как упрощение пользователю во внешнем менеджменте сервера. С ещё одной базой типа легче управляться чем с чем-то менее похожем (дополнительные темповыми файлами сервера).
+
Мне наоборот, кажется что сиквел слишком "упрощает" всё. Для меня намного логичней вообще строить систему не на файловой системе, а на блочном устройстве (дисках) напрямую/целиком.

А на аргумент - мол эмулировать ещё файловую систему?!
1. Это тот же MS - чё, разрабы не могут библиотеками обмениваться?
2. Всё кардинально упрощается.
Это неприемлемо для обычного пользователя. И абстракции рулят - но не более и не везде.

Да, с этой точки зрения скуль для домашнего, а не корпоративного использования.

С другой стороны PDW сиквел это надстройка над такими "серьёзными" системами.

Может вы имеете что те пару кило/мегов другого кода (вместо кила костылей) настолько тяжеелее поддерживать чем то гигантское разнообразие текущего функционала?

invm
Использование в пользовательской транзакции табличной переменной вместо обычной временной таблицы приведет к появлению в журнале записей LOP_BEGIN_XACT и LOP_BEGIN_XACT/LOP_ABORT_XACT на каждый чих с табличной переменной, т.к. этот самый чих физически будет выполняться в автономной транзакции. А COMMIT приводит к сбросу буфера журнала на диск.
Насчет последнего, в разрезе tempdb, не уверен, но пока что опровержения не нашел.
Ну это вы уже говорили выше, но я не понял, что показывает тогда ваш код 14498776.
Я вместо @ тупо подставил # таблицу и вижу что @ "жрёт" меньше. Может вы исправите тест ? (вы в этом разбираетесь)
+
use tempdb;
go

create table dbo.TestTable (i int);
create table #tr (tid varchar(30), tn sysname);

insert into dbo.TestTable
select top (10)
 a.object_id
from
 sys.objects a cross join
 sys.objects b

checkpoint;---------------------------------------------------------
GO
begin tran TestTransaction1;

declare @t table (i int);
insert into @t select i from dbo.TestTable;

delete top (50) percent from @t; 

commit;
--rollback;

insert into #tr
select
 [Transaction ID], [Transaction Name]
from
 fn_dblog(null, null)
where
 SPID = @@spid and
-- Operation IN ('LOP_BEGIN_XACT','LOP_ABORT_XACT') and
 [Transaction Name] in ('TVQuery', 'TestTransaction1');
 
select
 t.tn, l.*
from
 #tr t join
 fn_dblog(null, null) l on l.[Transaction ID] = t.tid
order by
 [Current LSN];

truncate table #tr

checkpoint;---------------------------------------------------------
GO
begin tran TestTransaction2;

create table #t (i int);
insert into #t select i from dbo.TestTable;

delete top (50) percent from #t; 

commit;
---rollback;

insert into #tr
select
 [Transaction ID], [Transaction Name]
from
 fn_dblog(null, null)
where
 SPID = @@spid and
-- Operation IN ('LOP_BEGIN_XACT','LOP_ABORT_XACT') and
 [Transaction Name] in ('TVQuery', 'TestTransaction2');
 
select
 t.tn, l.*
from
 #tr t join
 fn_dblog(null, null) l on l.[Transaction ID] = t.tid
order by
 [Current LSN];
go
 
drop table #t, #tr, dbo.TestTable;
go
2 июл 13, 01:36    [14507852]     Ответить | Цитировать Сообщить модератору
 Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
invm
Member

Откуда: Москва
Сообщений: 9633
Mnior
Лог/грязные страницы/... скидывается на диск как-то?! Какой-то внутренней системной "функцией".
И почему вместо её повторного использования, надо повторно использовать высоко-уровневые абстракции типа таблица?
Потому что и временные таблицы, и табличные переменные - практически полноценные таблицы.
Mnior
Может вы имеете что те пару кило/мегов другого кода (вместо кила костылей) настолько тяжеелее поддерживать чем то гигантское разнообразие текущего функционала?
Я не только это имел в виду. Зачем логическую "нетранзакционность" реализовывать физической "нетранзакционностью", если можно использовать уже имеющиеся "транзакционные" механизмы? Профит превысит затраты? Не думаю.
Mnior
Я вместо @ тупо подставил # таблицу и вижу что @ "жрёт" меньше. Может вы исправите тест ? (вы в этом разбираетесь)
+ Пример
use tempdb;
go

create table #tr (tid varchar(30), tn sysname);

create table dbo.#t (i int);
declare @t table (i int);

insert into #t values (1);
insert into @t values (1);

checkpoint;---------------------------------------------------------

begin tran TestTransaction;

insert into #t values (1);
insert into #t values (1);
insert into #t values (1);
insert into #t values (1);

commit;

insert into #tr
select
 [Transaction ID], [Transaction Name]
from
 fn_dblog(null, null)
where
 SPID = @@spid and
 [Transaction Name] in ('TVQuery', 'TestTransaction');
 
select
 '#t', count(*), sum([Log Record Length] + [Log Reserve])
from
 #tr t join
 fn_dblog(null, null) l on l.[Transaction ID] = t.tid;

/*---------------*/
truncate table #tr;
/*---------------*/

checkpoint;---------------------------------------------------------

begin tran TestTransaction;

insert into #t values (1);
insert into @t values (1);
insert into @t values (1);
insert into @t values (1);

commit;

insert into #tr
select
 [Transaction ID], [Transaction Name]
from
 fn_dblog(null, null)
where
 SPID = @@spid and
 [Transaction Name] in ('TVQuery', 'TestTransaction');
 
select
 '@t', count(*), sum([Log Record Length] + [Log Reserve])
from
 #tr t join
 fn_dblog(null, null) l on l.[Transaction ID] = t.tid;
go

drop table #tr, #t;
go
2 июл 13, 11:34    [14509276]     Ответить | Цитировать Сообщить модератору
 Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
Александр52
Member

Откуда: Кокосовые острова ส็็็็็
Сообщений: 5134
Бока
1. На интервью мне задали следующий вопрос.

Есть таблица "TableA" с полями "col1" INT и "col2" VARCHAR(512).
Нужно сделать запрос
SELECT * FROM TableA
WHERE col2 = '<полный текст значения поля>'

По мнению интервьюера делать индекс на поле "col2" нецелесообразно из-за его длины

Вопрос интервьюера: как можно убыстрить выполнение указанного запроса, не строя индекс на поле "col2" ?


Поднять Sphinx, построить его индекс - получаете сумасшедшую производительность \ скорость.
http://sphinxsearch.com/
2 июл 13, 11:36    [14509297]     Ответить | Цитировать Сообщить модератору
 Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
invm
Потому что и временные таблицы, и табличные переменные - практически полноценные таблицы.
Вы издеваетесь?
"Амёба и человек практически идентичны ибо животные."
Что за категории "аргументов"?
invm
Зачем логическую "нетранзакционность" реализовывать физической "нетранзакционностью"
Кхм. Опять стёб?
И во вторых, нет такого однозначного (физически одно-вариантного) понятия как "транзакционность". ибо её (и много других вещей) можно реализовать физически множествами способов.
invm
если можно использовать уже имеющиеся "транзакционные" механизмы? Профит превысит затраты?
Да, приносит, и этот "принцип чайничка" мне кажется от лени.
Более того, используя туже самую вашу "логику" - memory table в 2014 также "практически те же таблицы" - нет смысла реализовывать. Но их же реализовали.

invm, вы же гуру и знаток внутренностей скуля. Я не понимаю почему сейчас вы занимаете поверхностно схоластикой?

А логика советов не использовать табличные переменные из спама лога, в таком ракурсе вообще выносит моск.

invm
<Пример>
Спасибо! На этом примере, при @ лог почти в 4 раза больше (по объёму) чем при #.
Но в тесте ниже я убрал какие либо ограничения по транзакциям - т.е. сюда попали действия со созданию и уничтожению таблиц и их метаданных.
+ код теста, типизированный
USE tempdb;
GO
CREATE VIEW dbo.VLog AS
WITH Trans AS (
	SELECT	DISTINCT T.[Transaction ID]
	FROM	sys.fn_dblog(NULL,NULL)	T
	WHERE	T.SPID = @@SPID
)
SELECT	 L.*
	,Count(*)OVER()						AS [Count]
	,Sum(L.[Log Record Length] + L.[Log Reserve])OVER()	AS [Size]
FROM	Trans T JOIN sys.fn_dblog(NULL,NULL) L on L.[Transaction ID] = T.[Transaction ID]
GO
CREATE PROC dbo.spTestTableVar
	 @Tran	Bit
	,@Batch	Bit
AS BEGIN
	SET NOCOUNT ON;

	DECLARE @Table TABLE (PK Int PRIMARY KEY);

	IF (@Tran IS NOT NULL) BEGIN TRAN TTestTableVar;

	IF (@Batch = 1)
		INSERT @Table VALUES (1),(2),(3),(4),(5);
	ELSE BEGIN
		INSERT @Table VALUES (1);
		INSERT @Table VALUES (2);
		INSERT @Table VALUES (3);
		INSERT @Table VALUES (4);
		INSERT @Table VALUES (5);
	END

	IF (@Tran = 1)
		COMMIT   TRAN TTestTableVar;
	ELSE IF (@Tran = 0)
		ROLLBACK TRAN TTestTableVar;
END
GO
CREATE PROC dbo.spTestTableTemp
	 @Tran	Bit
	,@Batch	Bit
AS BEGIN
	SET NOCOUNT ON;
	CREATE TABLE #Table (PK Int PRIMARY KEY);

	IF (@Tran IS NOT NULL) BEGIN TRAN TTestTableTemp;

	IF (@Batch = 1)
		INSERT #Table VALUES (1),(2),(3),(4),(5);
	ELSE BEGIN
		INSERT #Table VALUES (1);
		INSERT #Table VALUES (2);
		INSERT #Table VALUES (3);
		INSERT #Table VALUES (4);
		INSERT #Table VALUES (5);
	END

	IF (@Tran = 1)
		COMMIT   TRAN TTestTableTemp;
	ELSE IF (@Tran = 0)
		ROLLBACK TRAN TTestTableTemp;
END
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableVar 0,0
SELECT	'@', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableTemp 0,0
SELECT	'#', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableVar 1,0
SELECT	'@', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableTemp 1,0
SELECT	'#', * FROM dbo.VLog
GO
--------------------------------------------------------------------------------
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableVar 0,1
SELECT	'@', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableTemp 0,1
SELECT	'#', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableVar 1,1
SELECT	'@', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableTemp 1,1
SELECT	'#', * FROM dbo.VLog
GO
--------------------------------------------------------------------------------
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableVar NULL,0
SELECT	'@', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableTemp NULL,0
SELECT	'#', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableVar NULL,1
SELECT	'@', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableTemp NULL,1
SELECT	'#', * FROM dbo.VLog
GO
DROP VIEW dbo.VLog; DROP PROC dbo.spTestTableVar, dbo.spTestTableTemp;
-- ROLLBACK
TranType@Count@Size#Count#Size
RollBackMulti1201265366560184
CommitMulti20574322734808
RollBackBatch12201363134533
CommitBatch12201362734808
NoTranMulti20574323572073
NoTranBatch12201362734792
Результат стабилен (размер лога незначительно прыгает в малых долях %).
Как мы видим, хотя по таблице лог меньше в случае обворачивания в одну транзакцию, но он всётаки зависит от количества команд в батче. В архиве все логи, для проверок "аномалий".
Ну и вопрос, почему так разнятся логи. Скорее у вас могут быть другие результаты, ибо версия по рукой: 2008 R2 (RTM) - 10.50.1600.1 (X64).
Видно, что не так всё однозначно.

В среднем, чаще применяются времянки для хранения временных результатов. Т.е. один раз заганяются данные и потом юзаются.
Поэтому табличные переменные не так уж плохо. IMXO
Даже при идеатической реализации.

PS: В скуле есть автономные транзакции Но только одна TVQuery - для табличных переменных, и только на команду. Но вот реализовывать полный интерфейс к автономкам MS не хочет.

К сообщению приложен файл (Log.zip - 31Kb) cкачать
2 июл 13, 22:32    [14513259]     Ответить | Цитировать Сообщить модератору
 Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
 		Некто пытается сесть invm-у на голову.
4 июл 13, 00:48    [14519775]     Ответить | Цитировать Сообщить модератору
 Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
invm
Member

Откуда: Москва
Сообщений: 9633
Mnior
"Амёба и человек практически идентичны ибо животные."
Что за категории "аргументов"?
Ну, амеба все-таки не животное :)
Ок, зайдем с другой стороны, раз аргумент не подошел: как по вашему, временные таблицы и табличные переменные должны удовлетворять ACID? И даже не ACID. Давайте остановимся на AC из ACID.
Mnior
нет такого однозначного (физически одно-вариантного) понятия как "транзакционность". ибо её (и много других вещей) можно реализовать физически множествами способов.
Безусловно. Но это не ответ на вопрос "Зачем?"
Mnior
invm, вы же гуру и знаток внутренностей скуля
Вы мне очень сильно льстите.
Mnior
А логика советов не использовать табличные переменные из спама лога
Я такое советовал?
Mnior
Ну и вопрос, почему так разнятся логи
У вас скрипт немного не корректен. Процедуры должны быть с with recompile:
+
USE tempdb;
go
create table #t (id int identity, op_descr varchar(30), tran_descr varchar(30), cnt int, spaceused int);
go

CREATE VIEW dbo.VLog AS
WITH Trans AS (
	SELECT	DISTINCT T.[Transaction ID]
	FROM	sys.fn_dblog(NULL,NULL)	T
	WHERE	T.SPID = @@SPID
)
SELECT
	Count(*) AS[Count],
	Sum(L.[Log Record Length] + L.[Log Reserve]) AS [Size]
FROM	Trans T JOIN sys.fn_dblog(NULL,NULL) L on L.[Transaction ID] = T.[Transaction ID]
GO
CREATE PROC dbo.spTestTableVar
	 @Tran	Bit
	,@Batch	bit
with recompile
AS BEGIN
	SET NOCOUNT ON;

	DECLARE @Table TABLE (PK Int PRIMARY KEY);

	IF (@Tran IS NOT NULL) BEGIN TRAN TTestTableVar;

	IF (@Batch = 1)
		INSERT @Table VALUES (1),(2),(3),(4),(5);
	ELSE BEGIN
		INSERT @Table VALUES (1);
		INSERT @Table VALUES (2);
		INSERT @Table VALUES (3);
		INSERT @Table VALUES (4);
		INSERT @Table VALUES (5);
	END

	IF (@Tran = 1)
		COMMIT   TRAN TTestTableVar;
	ELSE IF (@Tran = 0)
		ROLLBACK TRAN TTestTableVar;
END
GO
CREATE PROC dbo.spTestTableTemp
	 @Tran	Bit
	,@Batch	bit
with recompile
AS BEGIN
	SET NOCOUNT ON;
	CREATE TABLE #Table (PK Int PRIMARY KEY);

	IF (@Tran IS NOT NULL) BEGIN TRAN TTestTableTemp;

	IF (@Batch = 1)
		INSERT #Table VALUES (1),(2),(3),(4),(5);
	ELSE BEGIN
		INSERT #Table VALUES (1);
		INSERT #Table VALUES (2);
		INSERT #Table VALUES (3);
		INSERT #Table VALUES (4);
		INSERT #Table VALUES (5);
	END

	IF (@Tran = 1)
		COMMIT   TRAN TTestTableTemp;
	ELSE IF (@Tran = 0)
		ROLLBACK TRAN TTestTableTemp;
END
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableVar 0,0
insert into #t (op_descr, tran_descr, cnt, spaceused) SELECT	'@, multi', 'rollback', * FROM dbo.VLog
go
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableTemp 0,0
insert into #t (op_descr, tran_descr, cnt, spaceused) SELECT	'#, multi', 'rollback', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableVar 1,0
insert into #t (op_descr, tran_descr, cnt, spaceused) SELECT	'@, multi', 'commit', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableTemp 1,0
insert into #t (op_descr, tran_descr, cnt, spaceused) SELECT	'#, multi', 'commit', * FROM dbo.VLog
GO
--------------------------------------------------------------------------------
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableVar 0,1
insert into #t (op_descr, tran_descr, cnt, spaceused) SELECT	'@, batch', 'rollback', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableTemp 0,1
insert into #t (op_descr, tran_descr, cnt, spaceused) SELECT	'#, batch', 'rollback', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableVar 1,1
insert into #t (op_descr, tran_descr, cnt, spaceused) SELECT	'@, batch', 'commit', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableTemp 1,1
insert into #t (op_descr, tran_descr, cnt, spaceused) SELECT	'#, batch', 'commit', * FROM dbo.VLog
GO
--------------------------------------------------------------------------------
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableVar NULL,0
insert into #t (op_descr, tran_descr, cnt, spaceused) SELECT	'@, multi', 'notran', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableTemp NULL,0
insert into #t (op_descr, tran_descr, cnt, spaceused) SELECT	'#, multi', 'notran', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableVar NULL,1
insert into #t (op_descr, tran_descr, cnt, spaceused) SELECT	'@, batch', 'notran', * FROM dbo.VLog
GO
CHECKPOINT;	----------------------------------------------------------------
EXEC dbo.spTestTableTemp NULL,1
insert into #t (op_descr, tran_descr, cnt, spaceused) SELECT	'#, batch', 'notran', * FROM dbo.VLog
go

select
 op_descr,
 sum(case when tran_descr = 'rollback' then cnt end) as [cnt rollback],
 sum(case when tran_descr = 'rollback' then spaceused end) as [spaceused rollback],
 sum(case when tran_descr = 'commit' then cnt end) as [cnt commit],
 sum(case when tran_descr = 'commit' then spaceused end) as [spaceused commit],
 sum(case when tran_descr = 'notran' then cnt end) as [cnt notran],
 sum(case when tran_descr = 'notran' then spaceused end) as [spaceused notran]
from
 #t
group by
 op_descr;
go

drop table #t;
DROP VIEW dbo.VLog; DROP PROC dbo.spTestTableVar, dbo.spTestTableTemp;
-- ROLLBACK
Результат:
op_descrcnt rollbackspaceused rollbackcnt commit spaceused commitcnt notranspaceused notran
#; batch836657478666047866588
#; multi8366574786660486103868
@; batch137975481379754813797548
@; multi145134844145134844145134844
4 июл 13, 11:45    [14521136]     Ответить | Цитировать Сообщить модератору
 Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
invm
Ну, амеба все-таки не животное :)
Ок, одноклеточных животных не бывает. Возьмём тогда блох.
invm
Ок, зайдем с другой стороны, раз аргумент не подошел: как по вашему, временные таблицы и табличные переменные должны удовлетворять ACID? И даже не ACID. Давайте остановимся на AC из ACID.
Вот!!! Вот это аргумент!
Consistency - не применим в текущей реализации. Но это отдельная большая под-тема: FK на времянки это абзац. :)
Atomicity - это верно, должно! Но это тоже тема, ибо в общем виде Atomicity должно быть верно и для всей транзакции в целом, а @ не откатишь.
C другой стороны убрать атомарность до уровня строки - тоже фишка, типа можно найти где рубанулось. :)

На стандартный лог накладывается свойство Integrity (целостность) что не нужно в данном случае и не надо путать его с атомарностью. Лог решает обе вещи, т.е. его стратегия заточена именно для этого.

Но в целом я согласен - он не так уж плохо решает задачу, если учесть то что лог tempdb совсем другой, чем лог обычной базы. Коммит в нём не сбрасывает его на диск. Т.е. да - в памяти он генерится - но до диска это не доходит.
Следовательно стоимость это лога может быть на порядок дешевле чем обычного. Но в сравнении @ и # это второстепенно.
Возможно вообще до диска доходят не все транзакции. Но это надо подтвердить.

Но возникает вопрос:
Атомарность каждой операции определяется соответствующими записями в логе. Т.е. что для @, что для # каждая операция атомарна и чуть ли не идентичны процессы.
Но почему для @ дороже ?

Как я понимаю атомарность работает как хранение операцией ссылки на последний элемент лога перед началом этой операции. Сама эта атомарность для целостности данных не нужно - в логе нет этих пометок. Только в случае откатов операции.
А в случае @ скуль делает глупость - создаёт транзакцию каждый раз, хотя мог бы сделать одну для всей сессии, для всех этих @. Более того, для всех неявных транзакций можно использовать туже стратегию SavePoint-ов. Экономия на спичках.

Неужели пора писать Suggestion на connect.microsoft.com ?
invm
У вас скрипт немного не корректен. Процедуры должны быть с with recompile
Позвольте с вами не согласиться.
Recompile, как я понимаю, убивает оптимизацию скуля, при котором он сохраняет структуру таблицы и повторно её использует для всех её вызовов. Т.е. типа таблица для всех одна, но с внутренним идентификатором процесса/вызова:
@ же не может мутировать в отличие от #. И накладные расходы для @ и # будут разные. Т.е. для статического кода @ эффективнее чем # - метаданные стабильны.
А # для процедурных императивистов, любителей простыни запутанного кода и курсоров.
+ клоновость
Что прикольно в PostgreSQL, там есть интерфейс клонировании таблиц. И на этом основывается секционирование.
Аналогично можно было и с времянками:
- простота использования
- стабильность метаданных - 0-ая стоимость
- возможна поддержка Consistency - аля FK для них и похожая лабудень

Надо протестировать и так и так. (Без recompile - надо как-то делать первый прогон. Кстати, как делать принудительный CheckPoint?)

Ваш тест чисто показывает именно случай использования Recompile.
А повышенный набор логов навевает что там затесалось ещё компиляция и элементы уже бесполезной оптимизации.

Ещё можно подсчитать стоимость подсчёта статистики для #.

PS: Спасибо что вы продолжаете копать дальше.
4 июл 13, 16:10    [14523290]     Ответить | Цитировать Сообщить модератору
 Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
andrey odegov
Member

Откуда:
Сообщений: 473
Mnior
Гавриленко Сергей Алексеевич
Ох уж эти мифы про нелогируемые табличные переменные. Все там честно логируется, просто данные в них не откатываются.
Осталось MS написать, зачем так.
Наверное, потому что при откате транзакции изменения "классических" переменных не откатываются
declare @i int = 1;
begin transaction;
set @i += 100500;
rollback;
select @i;
4 июл 13, 16:15    [14523320]     Ответить | Цитировать Сообщить модератору
 Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
 		Mnior: Почему 2 + 2 = 5, а не 4 ?
andrey odegov: Патамушта 2 + 2 = 4

Mnior
Осталось MS написать, зачем так.
andrey odegov, тогда имелось ввиду почему откат операции делается через лог, а не через версионность, к примеру.

Не сбивайте invm с мысли.
4 июл 13, 16:43    [14523538]     Ответить | Цитировать Сообщить модератору
 Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
Гость333
Member

Откуда:
Сообщений: 3683
invm
Ну, амеба все-таки не животное :)

Всё от классификации зависит. Захотели — отнесли к царству животных, захотели — сделали отдельное царство простейших.

В школьном учебнике биологии у нас было такое разделение:
— Царство Вирусы;
— Царство Доядерные организмы (или Бактерии);
— Надцарство Ядерные организмы, в которое входят три царства:
  • Растения;
  • Животные;
  • Грибы.

    Учебник был написан в 1980-е годы. Не думаю, что сейчас он катастрофически устарел. Согласно той классификации, амёба была как раз животным — синтезировать органические вещества из неорганики не умеет, потребляет в пищу органику (более того, по факту является хищником), способна самостоятельно передвигаться и т.п. :-)
    • 4 июл 13, 17:01    [14523646]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    Mnior
    Что прикольно в PostgreSQL, там есть интерфейс клонировании таблиц.

    Это вот такое?
    CREATE TABLE КопияМоейПрелести (LIKE МояПрелесть)

    Mnior
    Аналогично можно было и с времянками:
    - простота использования
    - стабильность метаданных - 0-ая стоимость
    - возможна поддержка Consistency - аля FK для них и похожая лабудень

    А почему бы тогда не как в Oracle. Один раз, заранее, создали временную таблицу — всё, метаданные фиксированы, времянкой можно пользоваться без предварительного CREATE TABLE.
    4 июл 13, 17:14    [14523726]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6723
    Гость333
    Всё от классификации зависит. Захотели — отнесли к царству животных, захотели — сделали отдельное царство простейших.
    Да, я именно вспомнил школьный курс. А вообще вот: http://elementy.ru/news/432022
    Гость333
    Это вот такое? 
    CREATE TABLE КопияМоейПрелести (LIKE МояПрелесть)
    PostgreSQL 9.2.4 Documentation / 5.8. Inheritance
    PostgreSQL 9.2.4 Documentation / CREATE TABLE
    CREATE TABLE capitals (
    state           char(2)
) INHERITS (cities);
    Таблиц может быть несколько. Но это OffTop OffCurrent. :)
    Гость333
    А почему бы тогда не как в Oracle. Один раз, заранее, создали временную таблицу — всё, метаданные фиксированы, времянкой можно пользоваться без предварительного CREATE TABLE.
    Согласен. Хотя смутно помню, но там геморрой был с этим.
    А если мне нужно несколько таблиц одновременно? Плодить копии?
    И как там кстати, завязано на текущем скоупе или "сам следи"?
    4 июл 13, 20:28    [14524542]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    Mnior
    А если мне нужно несколько таблиц одновременно? Плодить копии?

    Не очень понял, о каких таблицах идёт речь.

    Mnior
    И как там кстати, завязано на текущем скоупе или "сам следи"?

    При создании временной таблицы можно указать одну из двух опций:
    — ON COMMIT PRESERVE ROWS — это значит, что данные, вставленные во времянку, остаются там до окончания текущей сессии;
    — ON COMMIT DELETE ROWS — значение по умолчанию, данные из времянки удаляются при завершении транзакции.

    С одной стороны, заранее созданные времянки в Oracle удобны тем, что позволяют отслеживать раскомпилированные объекты БД.

    С другой стороны, в MSSQL любой пользователь, имея лишь права на коннект к серверу, может создавать времянки с любой структурой. Это может быть удобно, например, для отладки. В Oracle же для создания времянки нужны права CREATE TABLE, которые есть далеко не у всех.

    + Ну и в бочке с времянками Oracle есть своё огромное ведро дёгтя
    Согласно документации Oracle,
    автор
    Distributed transactions are not supported for temporary tables.

    На практике за этой невинной фразой кроется следующее. Времянкой в распределённой транзакции пользоваться можно — вставляем данные, обновляем, удаляем — нет проблем, Оракл не возразит ни слова. Коммитим транзакцию — тоже нет проблем. Проблемы _могут_ случиться, если откатить транзакцию. Скорее всего, откат произойдёт без проблем. Но в редких случаях в кэше Оракла что-то переклинивает. Иногда до такой степени, что с грохотом падает весь инстанс БД!

    То есть что получается с точки зрения разработчика: в БД создаётся некая, зачастую очень сложная, процедура. Отлаживается со всех сторон. Коммитится в систему контроля версий. Проходит тестирование. Сдаётся в эксплуатацию, все довольны.
    Через какое-то время разработчики другой подсистемы (которая может находиться на другом сервере) при разработке своего бизнес-процесса решают использовать эту процедуру. Если забыли проверить использование времянок — всё, проблема может вылезть уже на стадии эксплуатации. Но в любом случае первый разработчик вынужден с матами и проклятиями в сторону Оракла лезть в систему контроля версий и думать, как же исправить эту процедуру.

    А техподдержка Оракла делает морду кирпичом и говорит — ну мы же в документации говорили — не используйте времянки в распределённых транзакциях. А вы ослушались, теперь вот сами исправляйте свой код, а наш Оракл хороший, его не трожь.

    То же самое вроде бы относится и к автономным транзакциям, хотя я не вполне уверен.
    5 июл 13, 12:06    [14526719]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6723
    Гость333
    Не очень понял, о каких таблицах идёт речь.
    Несколько разных таблиц одинаковой структуры.
    Гость333
    — ON COMMIT PRESERVE ROWS — это значит, что данные, вставленные во времянку, остаются там до окончания текущей сессии;
    — ON COMMIT DELETE ROWS — значение по умолчанию, данные из времянки удаляются при завершении транзакции.
    А если вложенные процедуры к примеру, но одни и те же таблы, как оставить данные независимыми (не смешивались)?

    invm: 14523290
    6 июл 13, 01:02    [14530526]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    invm
    Member

    Откуда: Москва
    Сообщений: 9633
    Mnior
    Consistency - не применим в текущей реализации
    Consistency не только FK, но и check с unique. Которые вполне допустимы и для #, и для @.
    Mnior
    Atomicity - это верно, должно! Но это тоже тема, ибо в общем виде Atomicity должно быть верно и для всей транзакции в целом, а @ не откатишь.
    Ну для обхода этого и придумали автономные транзакции. Данные в @ модифицируются в автономной транзакции, которая вполне себе откатывается при нарушении тех же check или unique.
    Mnior
    Коммит в нём не сбрасывает его на диск
    Не сбрасывает буфер журнала на диск. Это все же несколько другое. Хотя все равно нуждается в подтверждении.
    Mnior
    Но возникает вопрос:
    Атомарность каждой операции определяется соответствующими записями в логе. Т.е. что для @, что для # каждая операция атомарна и чуть ли не идентичны процессы.
    Но почему для @ дороже ?
    Что, в данном контексте, вы имеете в виду под атомарностью операции?
    Mnior
    А в случае @ скуль делает глупость - создаёт транзакцию каждый раз, хотя мог бы сделать одну для всей сессии, для всех этих @
    В этом случае в игру вступает TIL. Или вы предлагаете работать с @ все время на RU?
    Mnior
    Позвольте с вами не согласиться.
    Recompile, как я понимаю, убивает оптимизацию скуля, при котором он сохраняет структуру таблицы и повторно её использует для всех её вызовов. Т.е. типа таблица для всех одна, но с внутренним идентификатором процесса/вызова:
    Все несколько сложнее. В случае ХП, сиквел пытается повторно использовать @: Если на момент выполнения ХП нет выполняющихся экземпляров этой же ХП, то будет повторно использована @, оставшаяся от последнего выполнения. В противном случае будет создан еще один экземпляр @. Отсюда следует, что при завершении выполнения ХП @ не уничтожается, а очищается. Что и видно в журнале. И все эти @ будут существовать в tempdb, пока план ХП живет кеше.
    Так что без recompile мы емеем скрытый оверхед в журнале для @.
    7 июл 13, 23:59    [14533606]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6723
    invm
    Consistency не только FK, но и check с unique. Которые вполне допустимы и для #, и для @.
    Наполовину беременна?
    invm
    Ну для обхода этого и придумали автономные транзакции.
    Любая кошка в темноте чёрная.

    Не знаю, зачем вы это написали. Но оно либо работает полностью или не работает.
    Видимо в продолжение софистических аналогий, забавы ради.
    invm
    Что, в данном контексте, вы имеете в виду под атомарностью операции?
    Вопрос был наводящим под дальнейшие высказывания. Вы же не отрицаете их?!
    invm
    Mnior
    А в случае @ скуль делает глупость - создаёт транзакцию каждый раз, хотя мог бы сделать одну для всей сессии, для всех этих @
    В этом случае в игру вступает TIL. Или вы предлагаете работать с @ все время на RU?
    Не понял причём тут Read Uncommited. Да и Transaction Isolation Level - это для чтения, а для изменения тут оно всё монописуально.
    Дело только в логе и не более, точнее в его организации.
    Вы скорее намекаете на некий не озвученный механизм внутреннего взаимодействия идентификаторов транзакций. Аля две транзакции не видят друг друга. Ерунда, естественно что нельзя поменять болт, и не поменяв при этом гайку.

    Полное отсутсвие Consistency&Atomacy - полное отсутствие всяких "логов". Недо-Consistency&Atomacy естественно что-то недо-логи. Тупое писание сплошняком, без всяких "отметок" (спама недо-транзакций).

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

    invm
    Так что без recompile мы емеем скрытый оверхед в журнале для @.
    Э-э-э, скорее наоборот, судя по циферкам. Не? Т.е. очистка стоит дешевле?
    Но главное, на основе ваших утверждений (жаль что про это нельзя прочитать где либо есчё по подробнее) уже проявляется картинка, аля сервис брокер лайт версия для процедурок.
    Случаем вы не учились в тайной академии по знанию скуля, а то пару коментов и сразу пару мегаблоков в понимании архитектуры.
    И только по инвайту? Короче завидую вашему терпению.

    Меня вот всё не оставляет другое. Лог в текущем формате всётаки направлен на надёжность и даже быстрое восстановление после сбоев. А в силу того что ещё Glory упоминал про всякое свопирование, то и подавно мне не нравится текущая реализация недо-атомарности @. (не говоря о излишнего спаминга недо-транзакций)
    Зачем писать новое+старое значение? Можно только старое - для отката и не более. Зачем вообще писать это в почти-базу?
    Да я бы даже согласился использовать Single-Insert-Only времянки (log-less). Для всего остального (паиграца) есть #.
    9 июл 13, 03:13    [14538999]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    роллбэк
    Guest
    Mnior
    Зачем писать новое+старое значение? Можно только старое - для отката и не более. Зачем вообще писать это в почти-базу?


    если Вы про TempDB, то в ее лог и так пишется только старое. именно что "для отката и не более"
    9 июл 13, 09:55    [14539499]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6723
    роллбэк
    если Вы про TempDB, то в ее лог и так пишется только старое. именно что "для отката и не более"
    Пруфф в студию.
    9 июл 13, 10:19    [14539611]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6723
    Mnior
    роллбэк
    если Вы про TempDB, то в ее лог и так пишется только старое. именно что "для отката и не более"
    Пруфф в студию.
    Просматривая лог, который я сохранил тут выше, видны вставляемые значения, которых быть по вашему не должно. 84 байта на вставку одно-колоночной строки - многовато.
    9 июл 13, 11:06    [14539856]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    invm
    Member

    Откуда: Москва
    Сообщений: 9633
    Mnior
    Но оно либо работает полностью или не работает.
    Оно - это кто? Атомарность? Ну так никто ее не отрицает. Непонятно только зачем откатывать @.
    Mnior
    Вопрос был наводящим под дальнейшие высказывания
    Тогда я не понял наводку.
    Mnior
    Не понял причём тут Read Uncommited.
    Вы же сами предложили: "А в случае @ скуль делает глупость - создаёт транзакцию каждый раз, хотя мог бы сделать одну для всей сессии, для всех этих @". Ну и как читать из незавершенной транзакции?
    Mnior
    Полное отсутсвие Consistency&Atomacy - полное отсутствие всяких "логов". Недо-Consistency&Atomacy естественно что-то недо-логи. Тупое писание сплошняком, без всяких "отметок" (спама недо-транзакций).
    И получим недо-таблицу. Допустим, мне понадобился временный набор с ограничением уникальности. Уникальность надо будет контролировать вручную? Или пользоваться обычными таблицами? Или такой набор - нонсенс?
    Mnior
    Э-э-э, скорее наоборот, судя по циферкам. Не? Т.е. очистка стоит дешевле?
    Если в процедуре вставили N строк в @, то при завершении процедуры будет N удалений из @. Это относится к insert ... values ... В результатах fn_dblog это хорошо видно.
    Mnior
    Зачем писать новое+старое значение? Можно только старое - для отката и не более.
    Как уже отвечали, - в журнал tempdb пишется только undo. Простой пример:
    +
    use tempdb;
go

create table #t (i int, c char(500) default 'a');
insert into #t (i) values (1);
go

checkpoint;

insert into #t (i) values (2);
select * from fn_dblog(null, null);
go

drop table #t;
go

use model;
go

create table t (i int, c char(500) default 'a');
insert into t (i) values (1);
go

checkpoint;

insert into t (i) values (2);
select * from fn_dblog(null, null);
go

drop table t;
go
    Обратите внимание на значение Log Record Length для LOP_INSERT_ROWS.
    Ну и
    http://msdn.microsoft.com/en-us/library/ms190768(v=sql.105).aspx
    Operations within tempdb are minimally logged. This enables transactions to be rolled back.
    ...
    In SQL Server, tempdb performance is improved in the following ways:

    Temporary tables and table variables may be cached. Caching allows operations that drop and create the temporary objects to execute very quickly and reduces page allocation contention.

    Allocation page latching protocol is improved. This reduces the number of UP (update) latches that are used.

    Logging overhead for tempdb is reduced. This reduces disk I/O bandwidth consumption on the tempdb log file.

    The algorithm for allocating mixed pages in tempdb is improved.


    ЗЫ: MS не придумал ничего нового в WAL. В SQL Server используется протокол ARIES.
    9 июл 13, 11:39    [14540072]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    Cammomile
    Member

    Откуда:
    Сообщений: 1214
         		Не знаю как в 2012, а в 2008р2 я отмечал случаи, когда на большом количестве длинных строк чексам давал одинаковые суммы для РАЗНЫХ строк.
    9 июл 13, 11:41    [14540095]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    Cammomile
    Member

    Откуда:
    Сообщений: 1214
         		2. Ещё был вопрос: когда целесообразно использоват temporary table, а когда table variable ?

    Когда @ дает выигрышь по времени

    Когда надо протащить данные сквозь транзакцию.

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

    к тому же # гораздо удобнее в отладке
    9 июл 13, 11:55    [14540204]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6723
    invm
    Атомарность? Ну так никто ее не отрицает. Непонятно только зачем откатывать @.
    Это я к вашему вопросу про выполнимость AC. В рамках транзакции оно не работает. Не откатывает.
    invm
    Тогда я не понял наводку.
    На то что транзакция и откат не связанные вещи. Откат - это ссылка на лог - не более. Писать эту ссылку не обязательно, и в рамках атомарности команды она и не пишется. Работа с транзакциями нужна для восстановления после сбоев (к AC не имеет прямого отношения).
    invm
    Вы же сами предложили: "А в случае @ скуль делает глупость - создаёт транзакцию каждый раз, хотя мог бы сделать одну для всей сессии, для всех этих @". Ну и как читать из незавершенной транзакции?
    Причём тут это?!
    Не ставьте это в тиски. Вы говорите о виртуальных понятиях, я только о физики лога. Эта "транзакция" не как не связана с реальной транзакцией - это всего лишь идентификатор логе. Текущий TVQuery - это также псевдо-транзакция. Никаких взаимодействий с другими процессами она не имеет и бессмысленна. Она нужна для идентификации своих записей в общем логе - не более.

    Я плохо разжёвываю?

    Смотрите. Не считая времянки - всё просто. Один идентификатор в логе на всю транзакцию. Один на все изменения. Атомарность команды также - одна ссылка на лог. Если что:
    * Откат команды - возврат всех действий по всем таблам до ссылки (в оперативе)
    * Откат транзакции (включая сбой) - возврат до физической метки "начало транзакции".

    В случае нарушения CA @ обязана иметь отдельный механизм. Текущая ситуация - имеется второй идентификатор псевдо-транзакция TVQuery. В случае отката команды - откатывается и как в рамках основной транзакции, так и в рамках псевдо.

    Нужна ли физическая метка в логе для этой псевдо TVQuery? Нет, ибо текущая команда и так хранит в оперативе ссылки.
    Проблема в другом - идентификация этих записей - вот я и предложил, что ссессия автоматом имеет некий идентификатор псевдо-транзакции для всех времянок. Максимум одна запись физической метки на всю ссессию.
    invm
    Ну и как читать из незавершенной транзакции?
    С другой стороны ДА, можно считать что все @ это незавершенная транзакция для всех других ссесий - она никому кроме её владельца недоступна, и грохается в конце.
    invm
    Mnior
    Полное отсутсвие Consistency&Atomacy - полное отсутствие всяких "логов". Недо-Consistency&Atomacy естественно что-то недо-логи. Тупое писание сплошняком, без всяких "отметок" (спама недо-транзакций).
    И получим недо-таблицу.
    Не "получим", а имеем. Это текущее положение. Я его просто описал с нужной стороны нужными словами.
    invm
    Допустим, мне понадобился временный набор с ограничением уникальности. Уникальность надо будет контролировать вручную? Или пользоваться обычными таблицами? Или такой набор - нонсенс?
    Какая нафиг уникальность в многопользовательской среде?!!! Эти времянки недоступны никому кроме сессии. Это раз.
    Уникальность тут совершенно не причём. Совершенно. Даже в рамках многопользовательской среды. Уникальность, да как и многое другое определяется фундаментальной физикой локировок - правильной последовательностью команд. Независимо от того кто этим инструментом пользуется и имеется ли механизмы поддерживающие атомарность или что-то другое.


    invm
    Mnior
    Э-э-э, скорее наоборот, судя по циферкам. Не? Т.е. очистка стоит дешевле?
    Если в процедуре вставили N строк в @, то при завершении процедуры будет N удалений из @. Это относится к insert ... values ... В результатах fn_dblog это хорошо видно.
    Это всё замечательно. Но вопрос был другой - почему в выше указанном тесте . В случае без recompile циферки меньше. 14513259
    - А меньше Б?
    - Да, А меньше Б.
    - Почему А меньше Б?
    - А больше Б потому что ....
    <разрыв шаблона>
    Ну хотя бы "А там ошибка в подсчёте" - вот это я бы понял.

    invm
    в журнал tempdb пишется только undo.
    Это конечно меня радует. Спасибо за пример (и за ссылки) - Поковыряю.
    Хотя я не очень понимаю зачем что-то писать в самом начале - когда для undo пойдёт лишь одна команда ClearAll.
    invm
    ЗЫ: MS не придумал ничего нового в WAL. В SQL Server используется протокол ARIES.
    Не понял, это предписание или стандарт? Ибо декларативную феню можно физически 100500 способами реализовать.
    Если стандарт (движок) то это много чё объясняет. пресловутое by design - ласапед не мой.

    Cammomile
    #все прочие случаи когда надо сохранять промежуточный результат
    к тому же # гораздо удобнее в отладке
    Ну, в большинстве случаев, и случаев итак мало, как раз и нужно максимум одноразово сохранить промежуточный результат (из-за ограничений скуля), а в ещё редких случаях #, и то если бы их небыло - ничего зазорного реальными таблами фигачить.
    9 июл 13, 13:44    [14541062]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6723
         		Ах да.
    Cammomile
    к тому же # гораздо удобнее в отладке
    Отладка для слабаков. Она должна быть в голове.
    Меня это не напрягало ни в одних языках, даже более того мне не нравится последняя тенденция "а напишу абы как в отладке всё поправлю". Ленимся господа. Спелчекер меня отупляет писать правильно.

    invm
    в журнал tempdb пишется только undo
    Ну теперь можно полностью отметать аргумент "принцип чайничка".
    Лог другой, алгоритмы другие. Тут вольно делать всё по другому чем в "обычной базе".
    9 июл 13, 14:50    [14541586]     Ответить | Цитировать Сообщить модератору
     Re: Эффективный поиск по длинному тексту и переменная типа table  [new]
    Mnior
    Member

    Откуда: Кишинёв
    Сообщений: 6723
    invm
    Ну и
    http://msdn.microsoft.com/en-us/library/ms190768(v=sql.105).aspx
    Operations within tempdb are minimally logged. This enables transactions to be rolled back.
    ...
    In SQL Server, tempdb performance is improved in the following ways:

    Temporary tables and table variables may be cached. Caching allows operations that drop and create the temporary objects to execute very quickly and reduces page allocation contention.

    Allocation page latching protocol is improved. This reduces the number of UP (update) latches that are used.

    Logging overhead for tempdb is reduced. This reduces disk I/O bandwidth consumption on the tempdb log file.

    The algorithm for allocating mixed pages in tempdb is improved.
    Полезно. Но мало и поверхностно.

    Польза в том что в принципе на времянки не действую ни TIL ни локировки, вааще. Ибо уровень взаимодействия - это менеджмент ресурсов - странички.
    Просто лучше думать не как "чё урезать" из имеющегося, а "что необходимо" какретна, в отрыве от имеющихся механизмов.
    9 июл 13, 15:14    [14541754]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: ←Ctrl  назад   1 [2] 3   вперед  Ctrl→      все
    Все форумы / Microsoft SQL Server Ответить