Запирание таблиц/выступов при создании дизайна

Question

У меня вопрос о блокировке таблиц/запросов.

1. ли Vertica замок некоторые таблицы или прогнозы в ходе процесса разработки новых проекций (или программно DBDesigner в Admintools)? Здесь я имею в виду таблицы/прогнозы, которые участвуют в новом дизайне. У меня есть подозрение, что в процессе проектирования исходные таблицы/проекции должны быть в согласованном состоянии, поэтому содержимое таблиц/проекций во время проектирования одинаково все время (это означает, что таблицы/проекции доступны только для чтения) , Проблема в том, что запись в базу данных во время проектирования невозможна.

2. Есть ли способ наблюдать за ним в файлах журналов? Я прошел через vertica.log, но ничего не было о блокировке таблиц/прогнозов.

3. Есть ли способ обойти замок? Я бы хотел нормально работать (писать, обновлять) с базой данных и в процессе проектирования.

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

Answer 1

Это мое понимание. Я бы еще проверить первое, но на основе моих наблюдений ...

1. только целевая проекция получает X замок. Таблица (и другие прогнозы) должна быть доступна для других операций DML.

2. Любые замки будут видны в виде locks и lock_usage. Я не думаю, что вы увидите это в журнале (хотя, возможно, есть опция ведения журнала, чтобы включить этот уровень детализации, возможно, потребуется спросить поддержку).

3. Поскольку он не блокируется, все должно быть в порядке. Однако, если я ошибаюсь, и проблемы возникают, вам придется скопировать таблицу, добавить новые прогнозы, обновить, затем ALTER TABLE T1, T2, temps RENAME TO temps, T1, T2;, чтобы обменять их. Затем DML обновит все изменения, внесенные вами в данные за это время.

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

Answer 2

Если конструктор базы данных запускается с параметром Incremental Design, тогда создаются дополнительные проекции. Однако, если разработчик базы данных запускается с параметром «Комплексный дизайн», тогда необработанные проекции отбрасываются, а старые проекции заменяются новыми проекциями.

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

Вы можете проверить журнал дизайнер базы данных на пути
/home/dbadmin/designer.log

2016-11-30 05:26:05 [Designer.sendCommand] Executing: select dbd_create_workspace('tet1',True); 
2016-11-30 05:26:05 [Designer.sendCommand] Status: 0. Result: ['0'] 
2016-11-30 05:26:05 [Designer.send_sql_text] Sending SQL: select dbd_create_design('tet1','tet1'); 
select dbd_set_design_ksafety('tet1','tet1','0'); 
select dbd_set_optimization_objective('tet1','tet1','Load'); 
2016-11-30 05:26:05 [Designer.sendCommand] Sending commands in /home/dbadmin//command.sql 
2016-11-30 05:26:05 Setting search path: SET search_path=sid,public; 
2016-11-30 05:26:05 [Designer.sendCommand] Executing: select dbd_create_design('tet1','tet1'); 
2016-11-30 05:26:06 [Designer.sendCommand] Status: 0. Result: ['0'] 
2016-11-30 05:26:06 [Designer.sendCommand] Executing: select dbd_set_design_ksafety('tet1','tet1','0'); 
2016-11-30 05:26:06 [Designer.sendCommand] Status: 0. Result: ['0'] 
2016-11-30 05:26:06 [Designer.sendCommand] Executing: select dbd_set_optimization_objective('tet1','tet1','Load'); 
2016-11-30 05:26:06 [Designer.sendCommand] Status: 0. Result: ['0'] 
2016-11-30 05:26:06 Design schemas are: sid 
2016-11-30 05:26:06 [Designer.send_sql_text] Sending SQL: select dbd_add_design_tables('tet1','sid.*'); 
2016-11-30 05:26:07 Examining table data... 
2016-11-30 05:26:07 [Designer.fPrint] Output: 
    Examining table data.. 

.