Odp: RE: RE: procopy

["Siergiej Szablykin" <SSzablykin@lukas.com.pl>]

  Proponuję dalszą konwersację poza listą. Jeżeli chodzi o rozmiar bazy, to chodziło mi o to, że nawed przy relatywnie małych bazach szybciej będzie skopiować pliki bazy prez kopiowanie systemowe niż przy użyciu procopy. Natomiast efektywność zazwyczaj rozumuje jako czas wykonania zadania. Jeżeli chodzi o większy stopień skomplikowania, to można napisać scrypty i zautomatyzować cały proces.
  Co do procopy, to polecenie to pozwala na skopiowanie podniesionej bazy, co moim zdaniem, nie jest zbytnio bezpieczne - skopiowana podniesiona baza jest, tak naprawdę, w stanie nieznanym.

Z poważaniem,
Siergiej Szabłykin.


>>> Przemyslaw.Zolczynski@db-24.pl 10/19 1:58  >>>
Drogi Panie Siergieju,

Zapewne ma Pan rację ale problem nie tkwi tylko w procopy,
bo i w momencie showcfg dostaję ERROR zamiast jasnej odpowiedzi (może ktoś
wie?)
Chodzi mi o to abym był pewien że baza jest poprawnie użytkowana,
czyli np. prawidłowymi narzędziami. Na przykład zrobienie z bazy dwu
wolumenowej,
bazy o trzech i więcej musi iść przez probackup do jednego pliku a potem
do docelowych 3 extentów, sa pewnie i inne operacje utrudnione w ten sam
sposób.
Nie chcę kiedyś w przyszłości zostać zaskoczony w nie miły sposób.
Z drugiej strony ja po Pańskim mailu na pewno będę używał "cp", przynajmniej
do osiągnięcia 6GB
(czyli czegoś się stale uczymy) 
pozdrawiam
Przemek

-----Original Message-----
From: Siergiej Szablykin [mailto:SSzablykin@lukas.com.pl] 
Sent: Friday, October 19, 2001 12:03 PM
To: progress@zeto.bydgoszcz.pl 
Subject: Odp: RE: procopy


  Nawed przy 6GB bazach "cp" + "prostrct repair"  jest szybsze niż procopy.

Z poważaniem,
Siergiej Szabłykin.


>>> Przemyslaw.Zolczynski@db-24.pl 10/19 11:46  >>>
można użyć cp z wielo wolumenową ale potem trzeba ją naprawiać itd.
(nieefektywne)

-----Original Message-----
From: Tomasz Judycki [mailto:tjudycki@tv.com.pl] 
Sent: Friday, October 19, 2001 10:28 AM
To: progress@zeto.bydgoszcz.pl 
Subject: Re: procopy


Przepraszam za glupie byc moze pytanie, ale dlaczego nie mozna uzyc 'cp'
zamiast 'procopy'? To jest baza wielowolumenowa?

Tomasz Judycki

Żółczyński Przemysław wrote:
> 
> No nic z tego po paru pytaniach i odpowiedziach zwątpili,
> doszli do wniosku że ta wersja nie jest support'owana i w związku z tym
nie
> będą się dalej doszukiwać.
> A procedura zgłoszenia faktycznie jest bardzo łatwa.
> Wiec gdyby ktoś słyszał o podobnym problemie (bardziej jak jemu zaradzić)
to
> proszę o kontakt.
> pozdrawiam Przemek
> 
> -----Original Message-----
> From: Pawel Dobrzynski [mailto:pdobrzyn@progress.com] 
> Sent: Monday, October 15, 2001 11:29 AM
> To: progress@zeto.bydgoszcz.pl 
> Subject: Re: procopy
> 
> Sądzę że tym powinien się zająć dział wsparcia technicznego. Procedura
> zgłoszenia (bardzo prosta, zresztą) jest opisana na stronie:
> http://www.progress.com/worldwide/pl/uslugi/serwis.htm 
> 
> Pozdrawiam,
> 
> Paweł Dobrzyński
> 
> Żółczyński Przemysław wrote:
> >
> > Witam,
> >
> > Zamiast wykonania kopii dostaję poniższe komunikaty, dlaczego
> > Solaris 7, Progress 7.3E01
> >
> > $ procopy $DB_POM/bank $DB_POM1/bank
> > A database named /home/bankier/db.pom1/bank already exists, do you want
to
> > replace it? (y/n)y
> >
> > Copying /home/bankier/db.pom/bank to /home/bankier/db.pom1/bank...
> >
> > Start writing data blocks
> > SYSTEM ERROR: Memory violation. (49)
> > ** Save file named core for analysis by Progress Software Corporation.
> (439)
> > Quit
> >
> > +plik protrace.721 o zawartości:
> > PROGRESS stack trace as of Mon Oct 15 07:10:39 2001
> > Command line arguments are
> >
> > uttrace() +0x94 from: /home/progress/dlc73E/bin/_dbutil
> > utcore() +0xbc from: /home/progress/dlc73E/bin/_dbutil
> > drexit() +0x1a4 from: /home/progress/dlc73E/bin/_dbutil
> > drExitOnTerm() +0x304 from: /home/progress/dlc73E/bin/_dbutil
> > _setuid() +0x60 from: /usr/lib/libc.so.1
> > printfx() +0x2c from: /home/progress/dlc73E/bin/_dbutil
> > mv_copyutil() +0x720 from: /home/progress/dlc73E/bin/_dbutil
> > mvutil() +0x1c8 from: /home/progress/dlc73E/bin/_dbutil
> > main() +0x68 from: /home/progress/dlc73E/bin/_dbutil
> > _start() +0x5c from: /home/progress/dlc73E/bin/_dbutil
> > ------
> > Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm 
> > Obsluga listy:  listserv@zeto.bydgoszcz.pl 
> > Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html 
> > ------
> 
> --
> mailto:pd@progress.com 
> http://www.progress.com/pl 
> 
> Progress Software Polska
> tel: (+48 22) 673-10-44
> fax: (+48 22) 610 94 83
> ------
> Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm 
> Obsluga listy:  listserv@zeto.bydgoszcz.pl 
> Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html 
> ------
> ------
> Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm 
> Obsluga listy:  listserv@zeto.bydgoszcz.pl 
> Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html 
> ------

-- 
Pozdrawiam!

Tomasz Judycki

Textus Virtualis Sp. z o.o.
Szaserów 3
04-293 Warszawa
tel/fax (48 22) 879 82 00
http://www.tv.com.pl 

------
Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm 
Obsluga listy:  listserv@zeto.bydgoszcz.pl 
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html 
------
------
Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm 
Obsluga listy:  listserv@zeto.bydgoszcz.pl 
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html 
------

------
Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm 
Obsluga listy:  listserv@zeto.bydgoszcz.pl 
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html 
------
------
Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm 
Obsluga listy:  listserv@zeto.bydgoszcz.pl 
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html 
------
------
Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm
Obsluga listy:  listserv@zeto.bydgoszcz.pl
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
------