Re: 'COPY' Statement

Primary Key. :)

A Primary Key is always a constraint, since it cannot be duplicated. For
example, if you have a PK generated by a sequence starting at zero, when
you restore your third database into new server you will have duplicated
values in this column and COPY command will fail.

-----Original Message-----
From: Renato Oliveira <renato(dot)oliveira(at)grant(dot)co(dot)uk>
To: Iñigo Martinez Lasala <imartinez(at)vectorsf(dot)com>
Subject: RE: [ADMIN] 'COPY' Statement
Date: Tue, 13 Apr 2010 08:59:34 +0100


Dear Iñigo,

Thank you very much. What do you mean by ‘pk’?

I am sorry.

Thank you very much

Renato

Renato Oliveira
Systems Administrator
e-mail: renato(dot)oliveira(at)grant(dot)co(dot)uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

From: Iñigo Martinez Lasala [mailto:imartinez(at)vectorsf(dot)com]
Sent: 13 April 2010 08:56
To: Renato Oliveira
Cc: pgsql-admin(at)postgresql(dot)org; Steve Fisher
Subject: Re: [ADMIN] 'COPY' Statement

I think it depends of your datamodel and specifically of your table
constraints.

For example, if you have a table with a pk generated by a sequence, you
will have to deal with it before importing into your New_DB02. But for a
plain log table without constrains you can dump it an import into your
"just loaded" New_DB02 without any problem.

-----Original Message-----
From: Renato Oliveira <renato(dot)oliveira(at)grant(dot)co(dot)uk>
To: pgsql-admin(at)postgresql(dot)org <pgsql-admin(at)postgresql(dot)org>
Cc: Steve Fisher <steve(dot)fisher(at)grant(dot)co(dot)uk>
Subject: [ADMIN] 'COPY' Statement
Date: Tue, 13 Apr 2010 08:42:19 +0100

Dear all,

I just had a thought, another one. Please the guys who have the powerful
knowledge I need your help ;-)

Let’s suppose

I have Three DB servers ,physical servers – let’s call them:

· Original_DB01

· New_DB02

· Third_DB03

1 – Let’s suppose I have a PostgreSQL on ‘Original_DB01’ server with a
Data Base of 162GB in size.

2 – Let’s suppose I buy a new server ‘New_DB02’ - all singing all
dancing cool server, RAID10, 25GB RAM, 64Bit etc.

3 – Let’s suppose I backup the old server with pg_dump to a file
“pg_dump_original_DB01”

4 – Let’s also suppose I backup the schema only from ‘Original_DB01’and
restore it to ‘Third_DB03’.

5 – Straight after I backup the schema, I stop PostgreSQL on
‘Original_DB01’.

6 – Then I restore the schema to ‘Third_DB03’ and point the application
to it.

7 – Let’s suppose the application can create tables and can start using
the database on ‘Third_DB03’ and adding new data.

8 – Let’s suppose I restore the FULL pg_dump file
“pg_dump_original_DB01” to ‘New_DB02’

9 – Once the pg_dump has been restored to ‘New_DB02’ I can then point
the application to it and data will be added to it straight away.

Question:

10 – Can I use ‘COPY’ statement to transfer the data from ‘Third_DB03’
to ‘New_DB02’ without ‘WIPING’ or Deleting the existing data?

I want to merge the DATA from ‘Third_DB03’ to ‘New_DB02’ without
deleting the Database or the existing data on the existing database.

Let me explain the Idea behind this craziness.

I am using ‘Third_DB03’ because the amount of data to be transferred
from it, will be minimum, and easy to and quick to ‘COPY’

This application has two part components (Data and Alarms)

We can get the data back in a very hard way, but without the data being
in the database we can’t generate alarms.

I would very much appreciate all your help on this idea, please.

I would be very glad and grateful for any comments and improvements on
this idea, picking the holes etc.

Thank you very much in advance

Renato

Renato Oliveira
Systems Administrator
e-mail: renato(dot)oliveira(at)grant(dot)co(dot)uk Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

P Please consider the environment before printing this email

CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website

P Please consider the environment before printing this email

CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).

OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website