[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: blad 1260



Witam,

Marek, ma racje: problem powinien zostac zgloszony do serwisu. Dolaczam sie takze do
wyrazonego "smutku" z powodu wersji Progress-a. Tym bardziej, ze jest to bug, ktory
zostal poprawiony w wersji 8 (o ile pamietam to 8.0B). Prosze sprobowac sugerowanego
obejscia z KBase.
Problem polega na tym, ze funkcja utftok() tworzy duplikat identyfikatora pamieci
dzielonej do zaalokowania. Radze upgrade ;-)

Pozdrawiam i wszystkiego najlepszego w Nowym Roku.

Marek

Marek Prokop wrote:

> Dzien dobry,
> Chociaz pisze Pan, ze przenoszenie miedzy filesystemami nic nie daje, moze warto
>
> sprobowac tego troche inaczej: wykonac kopie pliku bazy, z ktora jest problem
> pod inna
> nazwa, skasowac oryginalny plik , przywrocic poprzednia nazwe skopiowanego pliku
> - wg  sugestii z ponizszej rady z Progress Knowledge Base.
> Prawdopodobnie to jest jakis inny problem (dbipcs sugeruje, ze segmenty pamieci
> sa alokowane prawidlowo) - mysle, ze trzeba go sprobowac zglosic do serwisu
> Progressa
> (tel. 00 800 311 1264). Ach ta wersja 7 w fazie "retired" i to w banku !!!
> Marek Prokop
>
> DB-DOWN - error 1260 at startup - duplicate inode
>
> DB-DOWN - error 1260 at startup - duplicate inode
>
> If you are trying to start up a stand-alone database (for the sake of
> discussion we will call it AAA) and 1) the AAA.lg file reports error
> 1260 - shared memory in use by another process, and 2) promon
> indicates that AAA exists but is pointing to BBB and 3) yes, BBB is
> up and running (hence the error), this is an indication of an inode
> conflict.  (This was once observed after converting databases from
> version 6.2 to version 6.3.)
>
> Usually the content of AAA is correct and intact, but the inode used
> to seed shared memory is the same as BBB.db's inode. The problem is
> with AAA.db only; AAA.bi and AAA.lg are ok.  The way to get AAA a
> unique inode will depend on your system configuration.  Here are
> three possible scenarios:
>
> 1) If you have enough space in the same filesystem to have two copies
>    of the .db file:
>    a) login as root
>    b) mv AAA.db AAAbad.db  #AAAbad.db retains the problem inode
>    c) cp AAAbad.db AAA.db  #AAA.db gets a new inode
>    d) rm AAAbad.db         #regain disk space, release problem inode.
>
> 2) If you have enough space in a different filesystem to hold a copy
>    of the .db file:
>    a) login as root
>    b) mv AAA.db /other-file-system/AAA.db
>    c) touch bad.inode
>    d) mv /other-file-system/AAA.db AAA.db
>    e) rm bad.inode
>
> 3) If you do not have enough disk space for an additional copy of the
>    .db file:
>    a)login as root
>    b) backup your database
>    c) make a second backup (just to be sure)
>    d) rm AAA.db
>    e) touch bad.inode
>    f) restore your backup
>    g) rm bad.inode
>
> Progress Software Technical Support Note # 15092
>
> —ó3czynski Przemys3aw wrote:
>
>   Witam Wszystkich w nowym roku,
>   zaczynam rok w dziwny sposób, od b3edów baz Progress'a. Mam nadzieje ?e dla
>   Was bedzie to b3ahy problem i jak zwykle pomo?ecie. :)
>
>   Mam kopie bazy produkcyjnej/rzeczywistej tutaj oznaczonej jako
>   "/sciezka/baza-p", kiedy próbuje uruchomia te baze (przy otwartym oryginale
>   w multi) to dostaje komunikat nr 1260 Mówiący o zajetości tego obszaru
>   pamieci, je?eli orygina3 le?y to oczywiście moge uruchomia baze.
>   Przenoszenie pomiedzy filesystemami nic nie daje, serwer ju? by3 po3o?ony,
>   jak startuje "/sciezka/baza-p" - orygina3 w multi to $DLC/bin/proutil -C
>   dbipcs daje takie rezultaty:
>
>   PROGRESS Version 7.3E01 as of Thu May 29 09:57:52 EDT 1997
>
>   PROGRESS SHARED MEMORY STATUS
>         ID ShMemVer Seg# InUse Database
>          0     7352    0 Yes   /baza-1a
>        201     7352    0 Yes   /baza-2a
>   *     202     7352    0 Yes   /sciezka/baza-p
>   *     203     7352    1 -     /sciezka/baza-p
>        204     7352    0 Yes   /baza1
>        205     7352    0 Yes   /baza2
>        206     7352    0 Yes   /baza3
>
>   Problem jest w tym ?e przy otwartej bazie produkcyjnej musimy miea dostep do
>   tej kopii. Myśle ?e "bankowcy" to zrozumieją :)
>   Za wszelkie sugestie z góry dziekuje.
>
>   Progress 7.3E01
>   Solaris 7 , Sparc
>
>   pozdrawiam
>
>   Przemek —ó3czynski
>
>   Deutsche Bank 24 S.A.
>   Sekcja Informatyki
>   Centrum Rozliczen Wa3brzych
>   tel:  074 8426846
>   fax: 074 8422216
>
>   ------
>   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
> ------

--
************************************************************
    Marek Bujnarowski
    Senior Technical Support Engineer
    Progress Software EMEA,
    Schorpioenstraat 67, 3067 GG Rotterdam,
    The Netherlands

  E-mail: mbujnaro@progress.com     Web: http://www.progress.com
  Tel: +31-(0)10-2865-247                Fax: +31-(0)10-2865-225
  Support:  emeasupport@progress.com
************************************************************


------
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
------