New answers tagged migration
4
Given the next example:
CREATE TABLE A
(
[ID] VARCHAR(10) NOT NULL,
CONSTRAINT [PK_A] PRIMARY KEY ([ID])
);
CREATE TABLE B
(
[ID] INT PRIMARY KEY,
[A_ID] VARCHAR(10) NOT NULL,
CONSTRAINT [FK_B] FOREIGN KEY ([A_ID]) REFERENCES A([ID])
);
CREATE TABLE C
(
[ID] INT PRIMARY KEY,
[A_ID] VARCHAR(10) NOT NULL,
CONSTRAINT [...
2
To keep the relationate both data need has same data type.
One of the fields I am changing is used in foreign key contraints on a
number of other tables.
So I can't see another solution to do this:
Create a new column in table A and change constraint in table B to this new column:
1 - Create another column (colX) in table A
2 - Cast and repply date ...
0
MySQL Workbench Migration tool can help you do this task
1) To start the migration process, on the MySQL Workbench main screen, go to Database-> Migration Wizard.
2) We should check the prerequisites to confirm if we can continue the task. If everything looks fine, we can press on Start Migration.
3) In this step, we need to provide the information about ...
0
Try calling the COPY command instead to read the files into CV. It should be a simple matter to write a script that calls COPY on all data.
If that still does not give you the speed you want, run multiple COPY commands per table (for example, one per year of some date column)
2
You don't actually have to dump to upgrade a PostgreSQL instance. For example, you can bring up a new cluster with access to an older cluster using the pg_upgrade command. If you're using XFS you can even use --clone. I would read the rest of the docs for pg_upgrade.
If you're just looking to move the instance you can try pg_basebackup - though I'm not sure ...
0
It's infuriating that the only mention of this seemingly crucial piece of configuration is in the release notes from a major version ago...
Added a write-ahead log (WAL) heartbeat (that is, running dummy queries) for replication from a PostgreSQL source. This feature was added so that idle logical replication slots don't hold onto old WAL logs, which can ...
1
You can try to use Foreign Data Wrapper and tds_fdw
Or you can try pgloader.
Both work perfectly, are easy to set up and are packaged on any serious Linux distributions.
0
One approach that works (only if there are no foreign keys referring to the table) is to create a backup of the original table with its original data.
Before starting to test the migration:
Grab a copy of the old table definition to define a copy of it, with a unique name (e.g. append "_bak" to the table name) and all named constraints (using sp_rename on ...
0
The fastest way will be pg_upgrade with the -k option.
This way. you can get away with a few minutes down time, which is required to move the database metadata.
If you cannot afford a few minutes down time, you will have to resort to a trigger based replication method like Slony. This way, you can replicate the database to a current version and switch the ...
Top 50 recent answers are included
