экспорт объектов db для контроля версий

Question

Мы реализуем контроль версий для нашего проекта. В рамках этого мы должны проверить все объекты БД. У нас есть таблицы, процедуры, функции, пакеты, представление и материализованное представление. Проблема в том, что существует много объектов, и нам нужно поместить исходный код файла. например Существуют таблицы T1, T2, T3, и нам нужны файлы Table_T1.txt, которые будут иметь определение T1 (определение столбцов, индексы для таблицы и грантов) и т. Д. Для всех объектов.

я м курсе таблиц метаданных, таких как DBA_VIEWS, dba_source и DBMS_METADATA.GET_DDL и т.д., где я могу найти нужную информацию , но как вытащить эту информацию объект мудрым. В настоящее время мы работаем над тем, где мы собираем всю информацию для конкретного объекта, а затем разделяем (CUT - PASTE) на разные файлы. Есть ли разумный способ справиться с этим?

База данных - Oracle 10g

Answer 1

но как вытащить эту информацию объект мудрым.

Передача параметров должным образом. Тогда вы могли бы настроить ваш выход.

DBMS_METADATA.GET_DDL (object_type, object_name, object_owner) 

Например, чтобы получить МЕТАДАННЫЕ для всех таблиц пользователя SCOTT.

SQL> conn scott/tiger@pdborcl; 
Connected. 
SQL> set long 200000 
SQL> select dbms_metadata.get_ddl('TABLE',t.table_name, 'SCOTT') from US 

DBMS_METADATA.GET_DDL('TABLE',T.TABLE_NAME,'SCOTT') 
------------------------------------------------------------------------ 

    CREATE TABLE "SCOTT"."DEPT" 
    ( "DEPTNO" NUMBER(2,0), 
     "DNAME" VARCHAR2(14), 
     "LOC" VARCHAR2(13), 
     CONSTRAINT "PK_DEPT" PRIMARY KEY ("DEPTNO") 
    USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS 
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 
    BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) 
    TABLESPACE "USERS" ENABLE 
    ) SEGMENT CREATION IMMEDIATE 
    PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 
NOCOMPRESS LOGGING 
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 
    BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) 
    TABLESPACE "USERS" 


    CREATE TABLE "SCOTT"."EMP" 
    ( "EMPNO" NUMBER(4,0), 
     "ENAME" VARCHAR2(10), 
     "JOB" VARCHAR2(9), 
     "MGR" NUMBER(4,0), 
     "HIREDATE" DATE, 
     "SAL" NUMBER(7,2), 
     "COMM" NUMBER(7,2), 
     "DEPTNO" NUMBER(2,0), 
     CONSTRAINT "PK_EMP" PRIMARY KEY ("EMPNO") 
    USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS 
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 
    BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) 
    TABLESPACE "USERS" ENABLE, 
     CONSTRAINT "FK_DEPTNO" FOREIGN KEY ("DEPTNO") 
      REFERENCES "SCOTT"."DEPT" ("DEPTNO") ENABLE 
    ) SEGMENT CREATION IMMEDIATE 
    PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 
NOCOMPRESS LOGGING 
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 
    BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) 
    TABLESPACE "USERS" 


    CREATE TABLE "SCOTT"."BONUS" 
    ( "ENAME" VARCHAR2(10), 
     "JOB" VARCHAR2(9), 
     "SAL" NUMBER, 
     "COMM" NUMBER 
    ) SEGMENT CREATION DEFERRED 
    PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 
NOCOMPRESS LOGGING 
    TABLESPACE "USERS" 


    CREATE TABLE "SCOTT"."SALGRADE" 
    ( "GRADE" NUMBER, 
     "LOSAL" NUMBER, 
     "HISAL" NUMBER 
    ) SEGMENT CREATION IMMEDIATE 
    PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 
NOCOMPRESS LOGGING 
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 
    BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) 
    TABLESPACE "USERS" 

Таким образом, это дает мне DDL для всех таблиц в SCOTT схеме.

Кроме того, вы могли бы сделать то же самое для всех других объектов, как INDEXES, ROLES и т.д.

Чтобы получить DDL в текстовом файле, просто используйте SPOOL. Таким образом, вам понадобятся отдельные сценарии для разных типов объектов, которые будут закодированы в соответствующих текстовых файлах.

Answer 2

Простым фактом является то, что вы не можете обращаться с объектами базы данных, когда будете обрабатывать свои Java, C# или другие файлы.

Есть много причин, и я назову несколько:

Файлы хранятся локально на компьютере разработчика и изменение s/он делает не влияет на других разработчиков. Аналогично, на разработчика не влияют изменения, сделанные ее коллегой. В базе данных это (обычно) не так, и разработчики используют одну и ту же среду базы данных, поэтому любые изменения, которые были привязаны к базе данных, влияют на другие.

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

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

Процесс сборки кода выполняется путем получения метки/последней версии кода в пустой каталог и последующего выполнения компиляции. Вывод - это двоичные файлы, в которых мы копируем &, заменим существующие. Нам все равно, что было раньше. В базе данных мы не можем воссоздать базу данных, так как нам нужно поддерживать данные! Также развертывание выполняет сценарии SQL, которые были сгенерированы в процессе сборки.

При выполнении SQL-скриптов (с командами DDL, DCL, DML (для статического содержимого)) вы предполагаете, что текущая структура среды соответствует структуре при создании сценариев. Если нет, то ваши сценарии могут завершиться неудачно, поскольку вы пытаетесь добавить новый столбец, который уже существует.

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

Иногда сценарий в репозитории управления версиями не соответствует структуре тестируемого объекта, а затем ошибки производятся!

Есть еще много, но я думаю, что вы получили картину.

То, что я обнаружил, что работает следующая:

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

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

Статья, которую я написал об этом, была опубликована here, вы можете ее прочитать.