Подход к тестированию хранилища данных

Question

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

• Схемы проверки фактов и таблиц измерений согласно спецификации
• данных дублируют проверить факты и измерения таблицы
• просмотровых проверка для таблицы размеров

Есть ли что-нибудь еще, что я могу подтвердить здесь?

Кроме того, любопытно, как я могу проверить, правильно ли заполнены данные в таблицу фактов и количество строк, правильные суррогатные ключи и т. Д. С точки зрения разработчиков они используют сценарии DML для загрузки данных?

Answer 1

Тестирование базы данных

База данных проверяется в следующих трех направлениях:

1. Тестирование менеджера баз данных и инструментов мониторинга - Для проверки менеджера баз данных и средств мониторинга, они должны использоваться в создании, запуске и управлении тестовой базой данных .
2. функции базы данных

   тестирования - Вот список возможностей, которые мы имеем для теста:

   -Querying параллельно

   -Создание индекса параллельно

   -DATA нагрузки параллельно

Оценка производительности базы данных. Выполнение запросов играет очень важную роль в показателях производительности хранилища данных. Есть набор фиксированных запросов, которые необходимо запускать регулярно, и их следует тестировать. Чтобы протестировать специальные запросы, нужно пройти документ по требованию пользователя и полностью понять бизнес. Потратьте время, чтобы проверить самые неудобные запросы, которые бизнес может спросить против разных стратегий индексирования и агрегации. http://www.tutorialspoint.com/dwh/dwh_testing.htm

Также вы можете использовать ETL тестирование (Extract, Transform, и нагрузка). Методы тестирования ETL: 1) Проверьте правильность преобразования данных в соответствии с различными бизнес-требованиями и правилами. 2) Убедитесь, что все проецируемые данные загружены в хранилище данных без потери данных и усечения. 3) Убедитесь, что приложение ETL соответствующим образом отклоняет, заменяет значения по умолчанию и выводит недопустимые данные. 4) Убедитесь, что данные загружены в хранилище данных в течение предписанных и ожидаемых временных рамок, чтобы подтвердить повышенную производительность и масштабируемость.

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

Также вы можете проверить расписание, резервного восстановления, операционной среды, приложения и логистику Теста Для получения дополнительной информации о ETL Тестирование/Тестирование хранилищ данных, пожалуйста, посетите http://www.softwaretestinghelp.com/etl-testing-data-warehouse-testing/

UPD:

Создание индексов в параллельном формате

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

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

Табличные пространства для секционированных индексов должны создаваться параллельно так же, как и табличные пространства для секционированных таблиц.

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

CREATE INDEX I on fact(dim_1,dim_2,dim_3) LOCAL 
PARTITION jan95 TABLESPACE Tsidx1, 
PARTITION feb95 TABLESPACE Tsidx2, 
... 
PARALLEL(DEGREE 12) NOLOGGING; 

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

Parallel Query Tuning 

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

• симметричные многопроцессорные системы (SMP), кластеры, или в широком масштабе параллельные системы
полоса пропускания
• высокого ввода/вывода (то есть много файлов данных на многих различных диске диски)
• недоиспользуемые или периодически используемые процессоры (например, системы, в которых использование процессора обычно меньше, чем 30%)
• достаточной памяти для поддержки дополнительных процессов в памяти с интенсивным , такие как сорта, хеширования и/буферы ввода-вывода

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

Здесь вы можете прочитать об этом более подробно: http://docs.oracle.com/cd/A57673_01/DOC/server/doc/A48506/pqo.htm#1559

This ресурсы Я надеюсь, что будет полезно для вас: https://wiki.postgresql.org/wiki/Parallel_Query_Execution

https://technet.microsoft.com/en-us/library/ms178065%28v=sql.105%29.aspx

http://www.csee.umbc.edu/portal/help/oracle8/server.815/a67775/ch24_pex.htm#1978

Answer 2

Я ETL тестер , для проверки достоверности данных и тестирования качества данных в хранилище данных приведены ниже проверки

1) тестирование метаданных - тестирование структуры базовых таблиц и их структуры (в соответствии с проектным документом). 2) проверка данных - при проверке данных вы проверяете трансформации отображения с использованием SQL и PL/SQL. Обычно мы тестируем его с использованием источника и таблицы целевых таблиц, Source минус Целевая, Исходная цель пересечения и Цель минус Источник.

3) Повторяющаяся проверка: не требует избыточности в хранилище данных. 4) Проверка стратегии загрузки: проверить, является ли ваша целевая таблица SCD или удалена при перезагрузке (зависит от требований.)