I cloned a DB DB_AAA using backup utility.
I create a new DB DB_ZZZ
Using db2look, I create a ddl file containing all tables and schemas from DB_AAA
db2 -tvsf testfile.ddl
db2 -v RESTORE DATABASE DB_AAA
FROM "/backups"
TAKEN AT 20130612013105
TO "/db"
INTO DB_ZZZ
REPLACE EXISTING
On DB_AAA, the DB2 ADMIN is DB2PADM
On DB_ZZZ, the DB2 ADMIN is DB2TADM
After finishing the restore, I have some PACKAGES which are still under the schema DB2*P*ADM which is a big problem because it cannot be acccessed by applications using DBADMINNAME.PACKANGE_NAME to retrieve it.
Question: can I modifiy the name of the schema under which a package is installed? I don't have the scripts to recreate manually the packages so it would be my only solution.
Package Schema Version by sections Valid Format level Blocking
CS16 DB2PADM DB2PADM 52 Y 0 CS U
VS16 DB2PADM DB2PADM 52 Y 0 CS U
Related
I have created a Postgresql database A using liquibase changesets. Now, I'm creating an application that allows creating a new database B and copies the schema from database A in real-time including the liquibase changesets as the database can still be updated later. Note that at the time of the copied schema in database A could already be updated, making the base changesets outdated.
My main question would be:
How to copy PostgreSQL schema x from database a (dynamically generated at run-time) to b using liquibase? Database b could be on another server.
If it's not possible with liquibase, what other tools or approaches would make this possible?
--
Let me add more context:
We initialize a new database a schema using liquibase changeset.
We can add a new table and field to the database an at run-time. Or during the time when the application is running. For example, we add a new table people to the schema of database a, which is not originally in the changeset. This is done using liquibase classes too. So changeset is added to databasechangelog table.
Now, we create a new database b.
We want to import the schema of the database a to b, with people table.
I hope that is clear.
Thanks.
All schema changes must be run through your schema migration tool
The point of using a database schema migration tool such as Liquibase or Flyway is to have a “single source of truth” regarding the structure of your database tables. Your set of Liquibase changesets (or Flyway scripts) is supposed to be that single source of truth for your database.
If you are altering the structure of you database at runtime, such as adding a table named people, outside the scope of your migration tool, well, then you have violated the rules of the game. You will have defeated the purpose of using a schema migration tool. The intention of using a schema migration tool is that you make all schema changes through that tool.
If you need to add a table while running in production, you should be dropping the physical file for the Liquibase changeset (or Flyway script) into the file system of your database server environment, and then invoking Liquibase (or Flyway) to run a migration.
Perhaps you have been misunderstanding the sequence of events:
If you have built a database on server "A", that means you installed Postgres, created an empty database, then installed the collection of Liquibase changesets you have carefully built, then ran a Liquibase migration operation on that server.
When you go to create a database on server "B", you should be following the same steps: Install Postgres, create an empty database, installing the very same collection of Liquibase changesets, and then running a Liquibase migration operation.
Alternatively, if making a copy of server "A" to create server "B", that copy should include the exact same Liquibase changesets. So at the end of your copy process, the two databases+changesets are identical.
Here's how I solved this problem of mine using the Liquibase Java library:
1.) Export the changelog from the source database into a temporary file (XML).
Liquibase liquibase = new Liquibase(liquibaseOutFile.getAbsolutePath(), new FileSystemResourceAccessor(), sourceDatabase);
liquibase.generateChangeLog(catalogAndSchema, changeLogWriter, new PrintStream(liquibaseOutFile.getAbsolutePath()), null);
2.) Execute the temporary file to the new data source.
Liquibase targetLiquibase = new Liquibase(liquibaseOutFile.getAbsolutePath(), new FileSystemResourceAccessor(), targetDatabase);
Contexts context = new Contexts();
targetLiquibase.update(context);
Here's the complete code: https://czetsuya-tech.blogspot.com/2019/12/generate-postgresql-schema-using-java.html
I have a db2 database on a device which does not have internect connectivity and would like to move this database to another place. I have taken a backup from my database, can I use the 'restore' command to create a clone of this database?
To move a Db2 database from on-premise to Db2 Warehouse on Cloud, one option is to use IBM Lift CLI. https://www.lift-cli.cloud.ibm.com/
You will need to have internet connectivity from the place your data resides on-premise - either a Db2 database, or failing that CSV files.
If all you have is a Db2 backup image, you would need to restore that into a local database, or use the (chargeable) utility High Performance Unload to extract table data as CSV files from the backup image. IBM Lift CLI does not support Db2 backup images as a source for migration to the cloud.
Note that if you use CSV files, you will need to extract the DDL from the source database and create the empty tables on the target.
When I am restoring the database, by default data is going in C drive, but when I installed the db2 that time I specify the path in D drive only.
Also, sample database files created by db2 is stored in D drive.
Can anyone please tell me what is the issue?
I have run this command:
SELECT * FROM SYSIBMADM.DBPATHS
below is the result i fetched:
LOGPATH- D:\DB2\NODE000\SQL00001\SQLOGDIR\
DB_STORAGE_PATH- C:\
LOCAL_DB_DIRECTORY - D:\DB2\NODE000\SQLOGDIR\
DBPATH - D:\DB2\NODE000\SQL00001\
I Want to change this DB_STORAGE_PATH C:\ to D:\ for all the database which i will be restoring.
You can run db2set from db2 command line that will confirm you wheather db2 installed on path with other information;
db2-command-line> db2set
DB2_ATS_ENABLE=YES
DB2_CREATE_DB_ON_PATH=YES
DB2INSTPROF=C:\where\db2\installed\IBM\DB2\DB2COPY1
DB2COMM=TCPIP
You can get more information of Directory structure for your installed DB2 database product (Windows) here
You can run the following command SELECT * FROM SYSIBMADM.DBPATHS. This will give details of following variables of your installed db2 database;
LOGPATH
DB_STORAGE_PATH
LOCAL_DB_DIRECTORY
DBPATH
These commands will provide you enough information to locate your installed database. Then you can restore your database providing the exact path.
To add a storage path to an existing database, issue the following ALTER DATABASE statement:
ALTER DATABASE database-name ADD STORAGE ON storage-path
After adding one or more storage paths to the database, you may use the ALTER TABLESPACE statement to rebalance table spaces in the database so that they start to use the new storage paths immediately.
DB2 has a configuration parameter for the default path for databases, dftdbpath. In addition, the command db2sampl to create a sample database has an option dbpath to specify where to place that database.
db2sample -dbpath D:
The above would place the new database on drive D:.
You will find that there are default paths for certain operations. The overview of DB2 database manager configuration parameters has lists most of them.
For your specific issue I would assume that a parameter was changed some time after DB2 was installed and used initially.
For RESTORE be aware that the options TO and DBPATH are ignored if restoring an existing database.
I've Enterprise Architect v12 and I want to use its Database builder in order to create a live connection between it and a postgresql database.
This is what I've done:
I've downloaded and installed PostgreSQL 9.5
During installation I've installed with StackBuilder Npgsql v2.2.4.3-2 and psqlODBC (64 bit) v09.03.0400-1.
I've started pgAdmin III and I can connect to my local database. I've created a new one without problems.
I've created in EA a new project: in technology I've selected Database and Data model: PostgreSQL.
In DataModel -> Tables -> Tables I've added a table Table1 and I've created a column id (varchar and primary key)
In the same table I've added a Datatabase connection Database connection 1.
I double click on Database connection 1 and then I select ODBC based database. Then click OK
At this point I'm not able to select my postgresql database. The data origin window (I don't know if it's the right name I've the italian version of windows) gives me two tabs: File origin data and computer origin data. In the first case inside the postgresql data folder that I've selected during installation I don't find anything useful, while in the second case I can see only Excel files and MS Access Database. If I click on New button I can select the data origin only for the current user and in the list I can't see postgresql (SQL Server, Microsoft paradox, etc).
What I'm doing wrong? How can I read my posgresql database from EA?
Enterprise Architect only connects to 32 bit ODBC datasources.
You can access the 32 bit ODBC manager from within EA from Tools|ODBC Data Sources or directly in windows from c:\Windows\SysWOW64\odbcad32.exe
Please let me know the steps on importing DB2 database exported from Commerical Version (DB2 8/9 ) to free DB2 ExpressC Edition(10).
As long as you are trying to restore into a DB2 Express C running in the 'same platform'(Same OS and same/higher bit level), you should not face any issue with the normal 'RESTORE' command.
If it is otherwise, it gets a little trickier. You can use the 'db2look' command to copy the schema(DDLs) creation SQLs and then run them in new machine to recreate the schema. Then you should use 'db2move' to move the user data present in the tables.
First of all, in DB2 there is no limitation about database size in free edition. Just CPU limitation exist. So there won't be any issue about porting you database to free edition.
Here is step by step way to do it. On old system:
# db2look -d DBNAME -e -o DBNAME.DDL
# db2move DBNAME export
After moving all generated files to new system, issue these commands on new system:
# db2 CREATE DATABASE DBNAME
# db2 -tvf DBNAME.DDL
# db2move DBNAME IMPORT
That's all.