Все технические форумы на одном сайте Удобный поиск информации с популярных форумов в одном месте
Вопрос: Про ожидания Buffer latch и логику MS SQL

Занимался оптимизацией работы с Waits. У меня в топе стояли
buffer latch , buffer i\o , logging
По latch нашел статьи о необходимости файлы tempdb разбивать на файлы равные количеству ядер (либо подбирать экспериментально в зависимости от структуры приложения)

Тестовое приложение, которое интенсивно пишет данные в журнал проводок (1С) с нескольких десятков одинаковых фоновых заданий , стало работать существенно быстрее - раза в 2
Вопрос 1 по Latch насколько правильно сделать такое же разбиение для Log файлов для режима бэкапирования Simple? Или log пишется последовательно?
Вопрос 2 правильно ли я понимаю что поделить файл данных (таблицы + индексы) на несколько уже не даст такого эффекта т.е. SQL будет стремится выделять страницы для одной таблицы в одном файле даже если есть возможность распределить по нескольким
Ответ:
o-o
selis76
сбрасывать зафиксированные данные в один файл или несколько? Вроде при фиксации транзакций данные сбрасываются крупными блоками

данные сбрасываются не по коммиту,
а по чекпойнту или при заполнении Buffer Pool
(будете в 1 транзакции 400 Гиг переливать при памяти в 48Гиг,
неужто на диск ничего не пойдет и будет ждать коммит?
ну или наоборот: 1 байт изменили в транзакции, теперь что, по коммиту бежать его на диск писать?)
а в разные файлы хорошо писать, когда они на разных дисках

Согласен - неточно выразился
Вопрос: LEFT JOIN и Using join buffer (Block Nested Loop)

Доброго времени суток всем, хотелось бы попросить у сообщества помощи, т.к. не могу понять, это баг MySQL или я что-то делаю не так. Опишу проблему. Имеется таблица (table1), которая связывается с другой (table2) с помощью LEFT JOIN.
Если используется в выборке один столбец из table2, то индекс успешно используется.
SELECT
	`table1`.`id`,
	`table2`.`value`
FROM 
	`table1`
LEFT JOIN `table2` ON `table2`.`table1_id` = `table1`.`id`
WHERE 
	`table1`.`level` = 'test'

idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra
1SIMPLEtable1ALLNULLNULLNULLNULL49200Using where
1SIMPLEtable2refPRIMARYPRIMARY4test1.table1.id1NULL


Если используются два столбца из table1, то в EXPLAIN'е красуется загадочная надпись Using join buffer (Block Nested Loop), индекс не используется и запрос выполняется нереально долго.
SELECT 
	`table1`.`id`,
	`table2`.`value`, 
	`table2`.`count`
FROM 
	`table1`
LEFT JOIN `table2` ON `table2`.`table1_id` = `table1`.`id`
WHERE 
	`table1`.`level` = 'test'

idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra
1SIMPLEtable1ALLNULLNULLNULLNULL49200Using where
1SIMPLEtable2ALLPRIMARYNULLNULLNULL1Using where; Using join buffer (Block Nested Loop)


Пока в качестве решения данной проблемы решил добавить второй аналогичный LEFT JOIN.
SELECT 
	`table1`.`id`,
	`table2`.`value`, 
	`table3`.`count`
FROM 
	`table1`
LEFT JOIN `table2` ON `table2`.`table1_id` = `table1`.`id`
LEFT JOIN `table3` ON `table3`.`table1_id` = `table1`.`id`
WHERE 
	`table1`.`level` = 'test'

И теперь все работает замечательно, индексы используются.
idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra
1SIMPLEtable1ALLNULLNULLNULLNULL49200Using where
1SIMPLEtable2refPRIMARYPRIMARY4test1.table1.id1NULL
1SIMPLEtable3refPRIMARYPRIMARY4test1.table1.id1NULL


Теперь назревает вопрос, это норма или баг?
Ответ:
javajdbc
"глюков" = "нестабильности пограничного состояния"...

Вот нехрен было делать - почти два часа пробовал воспроизвести такое пограничное состояние на приведённом примере. Как и следовало ожидать - с нулевым результатом.
Вопрос: Page buffer

Page buffer в 2048 страниц по 8192 это много или мало для 120 усеров? Или лучше по старинке - опытным путем?
Ответ: Gallemar,

в классике размер процесса обычно больше размера кэша. Потому что если кэш 2048 по 8к, это всего 16 мегабайт. А в 2.5 средний размер процесса обычно бывает от 150 до 250мб.
Потому что внутри него - кэш БД, кэш метаданных, память на битовые маски индексов, кэш сортировки, и т.д.
Вопрос: Почему Buffer Cache показывает 0 Мб?

Почему Buffer Cache показывает 0 Мб?

Ведь в файле инициализации установлено:
db_cache_size = 48G

Версия 10g2
Ответ: кто-то из индусов забыл поменять при инициализации формы DB_BLOCK_BUFFERS на db_cache_size )
Вопрос: keep buffer pool

В Оракле есть возможность закрепить выборочно таблицы в невытесняемом куске буферного кэша.
Есть ли такая возможность в MsSQL?

автор
Постоянный буферный пул
(keep buffer pool)
DB_KEEP_CACHE_SIZE
Постоянно хранит блоки дан-
ных в памяти. У вас могут быть
маленькие таблицы, к которым
выполняются частые обращения,
и для предотвращения их удале-
ния из буферного кэша им можно
назначить постоянный буферный
пул при создании таблицы.
Ответ:
Andrew Harlan
Есть ли такая возможность в MsSQL?
Раньше была (dbcc pintable), сейчас - нет.
Вопрос: Buffer pool extension на RamDrive

Имеется SQL Server 2014 Enterprise Edition. На выделенном сервере 256 Гб памяти, все они нужны и используются. К серверу идут несколько сотен запросов в секунду.

Есть мысль перейти на SQL Server 2014 Standard Edition с 128 Гб max memory, включить Buffer pool extension на 128 Гб и поместить этот кеш на RamDrive.

Что из этого может получится, нужно ли ожидать существенного ухудшения производительности или может производительность не ухудшится?
Ответ:

Скорость чтения SSD До 2900 Мб/сек
Скорость записи SSD До 2200 Мб/сек
Вопрос: Persistent object. Что это такое ?

Здравствуйте форумчане, столкнулся с проблемой отсутствия информации, в которой ясно поясняется сущность persistent объекта.
У меня возникает ряд вопросов:
  • Что это вообще за объект ?
  • Какое отношение он имеет к базам данных ?

Внятным пояснениям буду очень благодарен.
Ответ: лучший ответ, спасибо)
Вопрос: Преобразование %Persistent -> JSON

Cache for Windows (x86-32) 2016.2 (Build 736U)
Проблема с преобразованием объекта %Persistent в JSON .

Daymor, надеюсь на твой отклик особенно ) видел ваше общение со Стефаном на и Стефан утверждает что в версии 2016.2 такая возможность задекларирована, но я попробовал и получил ошибку синстаксиса :

USER>Do obj.$toJSON(stream)
DO obj.$toJSON(stream)
^
<SYNTAX>
Ответ: servit, спасибо, попробую. Заголовок темы да, исправьте пожалуйста.
Вопрос: Ошибка в tempdb: Time-out occurred while waiting for buffer latch type 3 for page...

Полный тест
Error: Time-out occurred while waiting for buffer latch type 3 for page (11:485280), database ID 2.

Версия Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) Oct 28 2016 18:17:30 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64> (Build 9600: )

Checkdb выдает 0 ошибок.

Ошибка выплыла второй раз на пару недель.
Так как это tempDb, то а промежуток времени, между предыдущей ошибкой. Сервер минимум 1 раз перегружался. А также tempDb была пересена на другой диск (то есть вопроса к "битости" диска как бы быть не может).

В логе sql
за 4 минуты времени около 12 аналогичных ошибок. С buffer latch type 3 и buffer latch type 4. Все относятся к tempdb
и за 6 минут порядка 20и сообщений типа
Process 0:0:0 (0xad8) Worker 0x00000049EC400160 appears to be non-yielding on Scheduler 17. Thread creation time: 13150541410851. Approx Thread CPU Used: kernel 0 ms, user 124703 ms. Process Utilization 60%. System Idle 38%. Interval: 130882 ms.

Предыдущий раз. Встретил упоминание, что в 2005 версии это может быть конфликт многопоточности за дисковые ресурсы и рекомендацию увеличить количество файлов в базе. В tempdb сейчас состоит из 12 файлов (на 3х независимых IO)

куда дальше копать искать причину?
Ответ:
Dzianis
invm
В статье описано как пользоваться отладчиком для поиска причины этой ошибки.


Поиск файла дампа для дебагера закончился неудачей.
в файле лога нет упоминаний о пути и имени. Файловый поиск по диску то же ничего не дал.


а это что показывает?
select * from sys.dm_server_memory_dumps
Вопрос: 12c Transport Database - impdp "character string buffer too small"

Всем привет!

Наконец предоставилась возможность пощупать Transport Database в реальности. Очень понравилось, что в 12-ой версии dbms_file_transfer при копировании между разными платформами может на лету конвертировать endian!

Постановка задачи: перенести БД 11.2.0.3 (RHEL x64, 11 Tb, 3307 datafiles) -> 12.1.0.2 (AIX).

Был избран путь по дблинку


В тестовой конфигурации с одним пользовательским датафайлом всё отработало успешно.

А вот когда для реальной базы скопировал (dbms_file_transfer) файлы и запустил на целевом хосте
impdp system parfile=transport.par

[содержимое transport.par]
full=Y
directory=tr_dir
network_link=tr_link
transportable=always
version=12
logfile=trans_import.log
trace=1FF0300
transport_datafiles='<some_dir>/s_0028.dbf'
transport_datafiles='<some_dir>/r_0196.dbf'
transport_datafiles='<some_dir>/r_3615.dbf'
.......3308 строк.......

Появилась ошибка
Import: Release 12.1.0.2.0 - Production on Tue Oct 18 23:05:43 2016

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
Password:

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
ORA-39006: internal error
ORA-39065: unexpected master process exception in DISPATCH
ORA-06502: PL/SQL: numeric or value error: character string buffer too small

ORA-39097: Data Pump job encountered unexpected error -6502

В БД-приёмнике
db_files                             integer     10000

Нота изучена и применена
Errors during Transportable Tablespace Plugin: ORA-39123: Data Pump transportable tablespace job aborted ORA-06502: PL/SQL: numeric or value error: character string buffer too small (Doc ID 1587730.1)


Кодировка в bash выставлена, как в БД
export NLS_LANG=AMERICAN_AMERICA.CL8KOI8R


Есть ли у многоуважаемых коллег какие мысли на эту тему?

Буду благодарен за любые мысли и рекомендации. Спасибо!
Ответ: Решил всё-таки довести до конца во что бы то ни стало - отказался от варианта с дблинком, а пошёл по пути в дампом


В таком виде процедура миграции+апгрейда прошла успешно!

impdp system parfile=transport.par.10
FULL=Y

DUMPFILE=asp_blue_full.dmp
DIRECTORY=TICKET_xyz
logfile=trans_import.log
transport_datafiles=...

=========================================

Далее нужно разбираться с невалидными объектами, не работающими с 9-ми версиями дблинками и т.д. - но это уже совсем другая история.

В общем, вариант с дампом отработал, а по дблинку - нет.

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

=========================================

Спасибо всем поучаствовавшим!