Re: Yan: ERROR: could not read block 149

Merhaba,

12 Mayis gunu gerceklesen 2. PostgreSQL Konferansi sunumlari, web
sitesine yerlestirildi:

http://pgday.postgresql.org.tr/2012/program.php

adresinden sunumlara ulasabilirsiniz.

İyi çalışmalar,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

Merhaba,

Faydalı oldu, paylaşım için teşekkürler.
Ankara'da da düzenlenmesini ya da webcast olarak yayınlanmasını dileriz :)

İyi çalışmalar.

Fatih Mehmet Güler
http://fmguler.com/
http://www.linkedin.com/in/fmguler

30 Mayıs 2012 10:34 tarihinde Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> yazdı:

>
> Merhaba,
>
> 12 Mayis gunu gerceklesen 2. PostgreSQL Konferansi sunumlari, web
> sitesine yerlestirildi:
>
> http://pgday.postgresql.org.tr/2012/program.php
>
> adresinden sunumlara ulasabilirsiniz.
>
> İyi çalışmalar,
> --
> Devrim GÜNDÜZ
> Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
> PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
> Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
>

INFO:  analyzing "public.hareket"ERROR:  could not read block 149 of relation 1663/517477/498735: No such file or directory
ERROR:  could not read block 149 of relation 1663/517477/498735: No such file or directory

Merhabalar
Postgresql 8.3.7 sürüm (malesef Win server 2003) veritabanı sisteminde  veya "hareket" tablosunda vacuum, analyze ve reindex gibi işlemleri yapmaya çalıştığımda, veya adı geçen tabloyu içeren bir sorgu çalıştırdığımda üstteki uyarıyı alıyorum.
Sunucuya yarına kadar fiziksel erişimim yok, yalnızca veritabanına bağlanabiliyorum uzaktan.
Belliki Cluster da kayıp dosyalar var. Cluster i kopyalama imkanım olmadığı içinde "drop table" demeye cesaret edemedim, sonra hepten çalışmaz hale gelir sistem, yanarım. İşin kötü tarafı yakında alınan bir yedek yok, iyi tarafı ise problemli tablo zaten yılda bir değişir, onun yedeği var.
Önerisi ve/veya bu durumu daha önce deneyimleyen var mı? Tabloyu silmeye kalsam başıma kötü birşey gelir mi?

Uygar UZUNHASAN

tabloda index var mı ? psql ile \d public.hareket yazıp çıktısını paylaşır
mısın? tabloya select,insert vs.. atabiliyorsan muhtemelen indexlerden bir
tanesi patladı. şunu deneyebilirsin, aynı fieldlara bir index daha koy.
isimlerini değiştir. sonra eski index'i drop et. muhtemelen çözecektir.

10 Temmuz 2012 18:40 tarihinde Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>yazdı:

> INFO: analyzing "public.hareket"ERROR: could not read block 149 of
> relation 1663/517477/498735: No such file or directory
> ERROR: could not read block 149 of relation 1663/517477/498735: No such
> file or directory
>
> Merhabalar
> Postgresql 8.3.7 sürüm (malesef Win server 2003) veritabanı sisteminde
> veya "hareket" tablosunda vacuum, analyze ve reindex gibi işlemleri yapmaya
> çalıştığımda, veya adı geçen tabloyu içeren bir sorgu çalıştırdığımda
> üstteki uyarıyı alıyorum.
> Sunucuya yarına kadar fiziksel erişimim yok, yalnızca veritabanına
> bağlanabiliyorum uzaktan.
> Belliki Cluster da kayıp dosyalar var. Cluster i kopyalama imkanım
> olmadığı içinde "drop table" demeye cesaret edemedim, sonra hepten çalışmaz
> hale gelir sistem, yanarım. İşin kötü tarafı yakında alınan bir yedek yok,
> iyi tarafı ise problemli tablo zaten yılda bir değişir, onun yedeği var.
> Önerisi ve/veya bu durumu daha önce deneyimleyen var mı? Tabloyu silmeye
> kalsam başıma kötü birşey gelir mi?
>
>
>
> Uygar UZUNHASAN
>
>

select oid,relname from pg_class where oid =1663 or oid= 498735 or oid=
517477;

bununda çıktısını yollar mısın?

10 Temmuz 2012 19:24 tarihinde Erdinc Akkaya <hz(dot)root(at)gmail(dot)com> yazdı:

> tabloda index var mı ? psql ile \d public.hareket yazıp çıktısını
> paylaşır mısın? tabloya select,insert vs.. atabiliyorsan muhtemelen
> indexlerden bir tanesi patladı. şunu deneyebilirsin, aynı fieldlara bir
> index daha koy. isimlerini değiştir. sonra eski index'i drop et.
> muhtemelen çözecektir.
>
> 10 Temmuz 2012 18:40 tarihinde Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>yazdı:
>
> INFO: analyzing "public.hareket"ERROR: could not read block 149 of
>> relation 1663/517477/498735: No such file or directory
>> ERROR: could not read block 149 of relation 1663/517477/498735: No such
>> file or directory
>>
>> Merhabalar
>> Postgresql 8.3.7 sürüm (malesef Win server 2003) veritabanı sisteminde
>> veya "hareket" tablosunda vacuum, analyze ve reindex gibi işlemleri yapmaya
>> çalıştığımda, veya adı geçen tabloyu içeren bir sorgu çalıştırdığımda
>> üstteki uyarıyı alıyorum.
>> Sunucuya yarına kadar fiziksel erişimim yok, yalnızca veritabanına
>> bağlanabiliyorum uzaktan.
>> Belliki Cluster da kayıp dosyalar var. Cluster i kopyalama imkanım
>> olmadığı içinde "drop table" demeye cesaret edemedim, sonra hepten çalışmaz
>> hale gelir sistem, yanarım. İşin kötü tarafı yakında alınan bir yedek yok,
>> iyi tarafı ise problemli tablo zaten yılda bir değişir, onun yedeği var.
>> Önerisi ve/veya bu durumu daha önce deneyimleyen var mı? Tabloyu silmeye
>> kalsam başıma kötü birşey gelir mi?
>>
>>
>>
>> Uygar UZUNHASAN
>>
>>
>

Selamlar
Dediğiniz sorgunun sonucunda
herhangi bilgi dönmüyor, boş. İndex yok, yalnız primary key vardı,
kaldırdım ancak tekrar yerine koymak istediğimde aynı hatayı alıyorum.
Select işleminde de farklı değil. Yalnız insert edebildim ancak yeni insert ettiğim satırı sorgulamama veya silmeye engel oldu.

 Uygar UZUNHASAN

>________________________________
> Kimden: Erdinc Akkaya <hz(dot)root(at)gmail(dot)com>
>Kime: Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>
>Kopya: Postgres Listesi <pgsql-tr-genel(at)postgresql(dot)org>
>Gönderildiği Tarih: 10 Temmuz 2012 19:27 Salı
>Konu: Re: [pgsql-tr-genel] ERROR: could not read block 149
>
>
>select oid,relname from pg_class where oid =1663 or oid= 498735 or oid= 517477;
>
>
>bununda çıktısını yollar mısın?
>
>10 Temmuz 2012 19:24 tarihinde Erdinc Akkaya <hz(dot)root(at)gmail(dot)com> yazdı:
>
>tabloda index var mı ? psql ile \d public.hareket yazıp çıktısını paylaşır mısın? tabloya select,insert vs.. atabiliyorsan muhtemelen indexlerden bir tanesi patladı. şunu deneyebilirsin, aynı fieldlara bir index daha koy. isimlerini değiştir. sonra eski index'i drop et.  muhtemelen çözecektir.
>>
>>
>>10 Temmuz 2012 18:40 tarihinde Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com> yazdı:
>>
>>
>>INFO:  analyzing "public.hareket"ERROR:  could not read block 149 of relation 1663/517477/498735: No such file or directory
>>>ERROR:  could not read block 149 of relation 1663/517477/498735: No such file or directory
>>>
>>>
>>>Merhabalar
>>>Postgresql 8.3.7 sürüm (malesef Win server 2003) veritabanı sisteminde  veya "hareket" tablosunda vacuum, analyze ve reindex gibi işlemleri yapmaya çalıştığımda, veya adı geçen tabloyu içeren bir sorgu çalıştırdığımda üstteki uyarıyı alıyorum.
>>>Sunucuya yarına kadar fiziksel erişimim yok, yalnızca veritabanına bağlanabiliyorum uzaktan.
>>>Belliki Cluster da kayıp dosyalar var. Cluster i kopyalama imkanım olmadığı içinde "drop table" demeye cesaret edemedim, sonra hepten çalışmaz hale gelir sistem, yanarım. İşin kötü tarafı yakında alınan bir yedek yok, iyi tarafı ise problemli tablo zaten yılda bir değişir, onun yedeği var.
>>>Önerisi ve/veya bu durumu daha önce deneyimleyen var mı? Tabloyu silmeye kalsam başıma kötü birşey gelir mi? 
>>>
>>>
>>>
>>>Uygar UZUNHASAN
>>>
>>
>
>
>

Merhaba,
eğer insert edebiliyor iseniz tablonun genelinde bir sıkıntı yok.
muhtemelen bir index (fk ile gelen yada başka bir yerde) bozulmuş olmalı.
eğer insert edemiyor olsaydınız sequence `lerden şüphelenecektim. rica
etsem psql ile bağlanıp \d tablo_adi çıktısını yollayabilir misiniz? başka
birşey varsa çıktı belki yol gösterebilir.

11 Temmuz 2012 09:43 tarihinde Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>yazdı:

> Selamlar
> Dediğiniz sorgunun sonucunda herhangi bilgi dönmüyor, boş. İndex yok,
> yalnız primary key vardı, kaldırdım ancak tekrar yerine koymak istediğimde
> aynı hatayı alıyorum.
> Select işleminde de farklı değil. Yalnız insert edebildim ancak yeni
> insert ettiğim satırı sorgulamama veya silmeye engel oldu.
>
> Uygar UZUNHASAN
>
> ------------------------------
> *Kimden:* Erdinc Akkaya <hz(dot)root(at)gmail(dot)com>
> *Kime:* Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>
> *Kopya:* Postgres Listesi <pgsql-tr-genel(at)postgresql(dot)org>
> *Gönderildiği Tarih:* 10 Temmuz 2012 19:27 Salı
> *Konu:* Re: [pgsql-tr-genel] ERROR: could not read block 149
>
> select oid,relname from pg_class where oid =1663 or oid= 498735 or oid=
> 517477;
>
> bununda çıktısını yollar mısın?
>
> 10 Temmuz 2012 19:24 tarihinde Erdinc Akkaya <hz(dot)root(at)gmail(dot)com> yazdı:
>
> tabloda index var mı ? psql ile \d public.hareket yazıp çıktısını
> paylaşır mısın? tabloya select,insert vs.. atabiliyorsan muhtemelen
> indexlerden bir tanesi patladı. şunu deneyebilirsin, aynı fieldlara bir
> index daha koy. isimlerini değiştir. sonra eski index'i drop et.
> muhtemelen çözecektir.
>
> 10 Temmuz 2012 18:40 tarihinde Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>yazdı:
>
> INFO: analyzing "public.hareket"ERROR: could not read block 149 of
> relation 1663/517477/498735: No such file or directory
> ERROR: could not read block 149 of relation 1663/517477/498735: No such
> file or directory
>
> Merhabalar
> Postgresql 8.3.7 sürüm (malesef Win server 2003) veritabanı sisteminde
> veya "hareket" tablosunda vacuum, analyze ve reindex gibi işlemleri yapmaya
> çalıştığımda, veya adı geçen tabloyu içeren bir sorgu çalıştırdığımda
> üstteki uyarıyı alıyorum.
> Sunucuya yarına kadar fiziksel erişimim yok, yalnızca veritabanına
> bağlanabiliyorum uzaktan.
> Belliki Cluster da kayıp dosyalar var. Cluster i kopyalama imkanım
> olmadığı içinde "drop table" demeye cesaret edemedim, sonra hepten çalışmaz
> hale gelir sistem, yanarım. İşin kötü tarafı yakında alınan bir yedek yok,
> iyi tarafı ise problemli tablo zaten yılda bir değişir, onun yedeği var.
> Önerisi ve/veya bu durumu daha önce deneyimleyen var mı? Tabloyu silmeye
> kalsam başıma kötü birşey gelir mi?
>
>
>
> Uygar UZUNHASAN
>
>
>
>
>
>

On Wed, 2012-07-11 at 10:28 +0300, Erdinc Akkaya wrote:
> eğer insert edebiliyor iseniz tablonun genelinde bir sıkıntı yok.

Emin misin?

--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

evet abi, adam sonuçta insert edebiliyor. select te problem var. muhtemelen
bir index kendini kaybetmiştir. başka bir sıkıntıda olabilir tabi (toast
kullanacak veri ise toast tabloda da sıkıntı olabilir) ama bana genede
index problemi gibi geldi (disk problemi yoksa tabi) bi çıktı gelsin ona
göre konuşmak daha iyi olacak sanki.

sence neden olabilir abi?

11 Temmuz 2012 10:35 tarihinde Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> yazdı:

> On Wed, 2012-07-11 at 10:28 +0300, Erdinc Akkaya wrote:
> > eğer insert edebiliyor iseniz tablonun genelinde bir sıkıntı yok.
>
> Emin misin?
>
> --
> Devrim GÜNDÜZ
> Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
> PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
> Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
>

Altta tablonun çıktısını verdim, burada pek sıradışı bişey göremedim

                                              Tablo "public.hareket_fisi_eski"
            Kolon             |          Veri tipi          |
        Modifiers
------------------------------+-----------------------------+-------------------
---------------------------------------------
 id                           | integer                     | Null deil ntanml n
extval('hareket_fisi_eski_id_seq'::regclass)
 cariid                       | integer                     | Null deil
 belge_no                     | character varying           | Null deil
 tarih                        | date                        | ntanml now()
 opsiyon                      | date                        |
 tip                          | smallint                    |
 shipment_terms               | smallint                    |
 doviz                        | smallint                    | Null deil ntanml 1
 exchange_rate                | numeric                     | ntanml 1
 kullanici_id                 | integer                     |
 cari_adres_id                | integer                     |
 gorunen_not                  | character varying           |
 basim_not                    | character varying           |
 vade_suresi                  | integer                     | ntanml 0
 indirim_oran                 | numeric(10,4)               | ntanml 0
 kdv_toplami                  | numeric(16,4)               | ntanml 0
 otv_toplami                  | numeric(16,4)               | ntanml 0
 toplamtutar                  | numeric(20,4)               |
 acilis_zamani                | timestamp without time zone | ntanml now()
 parent_id                    | integer                     |
 tamamlandimi                 | boolean                     | ntanml true
 indirim_tutari               | numeric(20,4)               |
 baski_sayisi                 | integer                     | ntanml 1
 olusturan                    | character varying           | ntanml "current_us
er"()
 ol_zaman                     | timestamp without time zone | ntanml now()
 degistiren                   | character varying           |
 de_zaman                     | timestamp without time zone |
 bakim_makina_id              | integer                     |
 bakim_bakim_id               | integer                     |
 bakim_saat                   | integer                     |
 satinalma_fiyat_arastirma_id | integer                     |
 kdv_tevkifat                 | numeric(16,4)               | ntanml 0
 kdv_tevkifat_ne              | integer                     | ntanml 0
 bakim_santiye_id             | integer                     | ntanml 1
 cari_ilgili_id               | integer                     |

 
Uygar UZUNHASAN

>________________________________
> Kimden: Erdinc Akkaya <hz(dot)root(at)gmail(dot)com>
>Kime: Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>
>Kopya: Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>; Postgres Listesi <pgsql-tr-genel(at)postgresql(dot)org>
>Gönderildiği Tarih: 11 Temmuz 2012 10:41 Çarşamba
>Konu: Re: Yan: [pgsql-tr-genel] ERROR: could not read block 149
>
>
>evet abi, adam sonuçta insert edebiliyor. select te problem var. muhtemelen bir index kendini kaybetmiştir. başka bir sıkıntıda olabilir tabi (toast kullanacak veri ise toast tabloda da sıkıntı olabilir) ama bana genede index problemi gibi geldi (disk problemi yoksa tabi) bi çıktı gelsin ona göre konuşmak daha iyi olacak sanki.
>
>
>sence neden olabilir abi? 
>
>
>11 Temmuz 2012 10:35 tarihinde Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> yazdı:
>
>On Wed, 2012-07-11 at 10:28 +0300, Erdinc Akkaya wrote:
>>> eğer insert edebiliyor iseniz tablonun genelinde bir sıkıntı yok.
>>
>>Emin misin?
>>
>>--
>>Devrim GÜNDÜZ
>>Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
>>PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
>>Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
>>http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz
>>
>
>
>

Yok hayır, dump ile çıktı alamıyorum, aynı hatayı veriyor zira dump işlemi özünde copy/select into komutları gibi çalışıyor, zaten select çalışmıyor.
Servisi durdurmam şuan için mümkün değil, hem sistem çalışıyor hem de tekrar çalıştıramamaktan da korkuyorum.

 
Uygar UZUNHASAN

>________________________________
> Kimden: Erdinc Akkaya <hz(dot)root(at)gmail(dot)com>
>Kime: Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>
>Gönderildiği Tarih: 11 Temmuz 2012 11:46 Çarşamba
>Konu: Re: Yan: Yan: [pgsql-tr-genel] ERROR: could not read block 149
>
>
>merhaba,
>tablonun dump ile çıktısını alabiliyor musun? yada sunucu durdurma şansın var mı?
>
>
>11 Temmuz 2012 11:29 tarihinde Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com> yazdı:
>
>Altta tablonun çıktısını verdim, burada pek sıradışı bişey göremedim
>>
>>
>>
>>                                              Tablo "public.hareket_fisi_eski"
>>            Kolon             |          Veri tipi          |
>>       
Modifiers
>>------------------------------+-----------------------------+-------------------
>>---------------------------------------------
>> id                           | integer                     | Null deil ntanml n
>>extval('hareket_fisi_eski_id_seq'::regclass)
>> cariid                       | integer                     | Null deil
>> belge_no                     | character
varying           | Null deil
>> tarih                        | date                        | ntanml now()
>> opsiyon                      | date                        |
>> tip                          |
smallint                    |
>> shipment_terms               | smallint                    |
>> doviz                        | smallint                    | Null deil ntanml 1
>> exchange_rate                | numeric                     | ntanml
1
>> kullanici_id                 | integer                     |
>> cari_adres_id                | integer                     |
>> gorunen_not                  | character varying           |
>> basim_not                    | character varying          
|
>> vade_suresi                  | integer                     | ntanml 0
>> indirim_oran                 | numeric(10,4)               | ntanml 0
>> kdv_toplami                  | numeric(16,4)               | ntanml 0
>> otv_toplami                  | numeric(16,4)               | ntanml
0
>> toplamtutar                  | numeric(20,4)               |
>> acilis_zamani                | timestamp without time zone | ntanml now()
>> parent_id                    | integer                     |
>> tamamlandimi                 | boolean                     | ntanml
true
>> indirim_tutari               | numeric(20,4)               |
>> baski_sayisi                 | integer                     | ntanml 1
>> olusturan                    | character varying           | ntanml "current_us
>>er"()
>> ol_zaman                     | timestamp without time zone | ntanml
now()
>> degistiren                   | character varying           |
>> de_zaman                     | timestamp without time zone |
>> bakim_makina_id              | integer                     |
>> bakim_bakim_id               | integer                    
|
>> bakim_saat                   | integer                     |
>> satinalma_fiyat_arastirma_id | integer                     |
>> kdv_tevkifat                 | numeric(16,4)               | ntanml 0
>> kdv_tevkifat_ne              | integer                     | ntanml
0
>> bakim_santiye_id             | integer                     | ntanml 1
>> cari_ilgili_id               | integer                     |
>>
>> 
>>Uygar UZUNHASAN
>>
>>
>>
>>
>>
>>>________________________________
>>> Kimden: Erdinc Akkaya <hz(dot)root(at)gmail(dot)com>
>>>Kime: Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>
>>>Kopya: Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>; Postgres Listesi <pgsql-tr-genel(at)postgresql(dot)org>
>>>Gönderildiği Tarih: 11 Temmuz 2012 10:41 Çarşamba
>>>Konu: Re: Yan: [pgsql-tr-genel] ERROR: could not read block 149
>>>
>>>
>>>evet abi, adam sonuçta insert edebiliyor. select te problem var. muhtemelen bir index kendini kaybetmiştir. başka bir sıkıntıda olabilir tabi (toast kullanacak veri ise toast tabloda da sıkıntı olabilir) ama bana genede index problemi gibi geldi (disk problemi yoksa tabi) bi çıktı gelsin ona göre konuşmak daha iyi olacak sanki.
>>>
>>>
>>>sence neden olabilir abi? 
>>>
>>>
>>>11 Temmuz 2012 10:35 tarihinde Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> yazdı:
>>>
>>>On Wed, 2012-07-11 at 10:28 +0300, Erdinc Akkaya wrote:
>>>>> eğer insert edebiliyor iseniz tablonun genelinde bir sıkıntı yok.
>>>>
>>>>Emin misin?
>>>>
>>>>--
>>>>Devrim GÜNDÜZ
>>>>Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
>>>>PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
>>>>Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
>>>>http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz
>>>>
>>>
>>>
>>>
>
>
>

Merhaba,

On Tue, 2012-07-10 at 08:40 -0700, Uygar UZUNHASAN wrote:
> INFO: analyzing "public.hareket"ERROR: could not read block 149 of
> relation 1663/517477/498735: No such file or directory
> ERROR: could not read block 149 of relation 1663/517477/498735: No
> such file or directory
>
> Merhabalar
> Postgresql 8.3.7 sürüm (malesef Win server 2003) veritabanı sisteminde
> veya "hareket" tablosunda vacuum, analyze ve reindex gibi işlemleri
> yapmaya çalıştığımda, veya adı geçen tabloyu içeren bir sorgu
> çalıştırdığımda üstteki uyarıyı alıyorum.

http://www.postgresql.org/docs/9.1/static/release-8-3-18.html

Fix btree index corruption from insertions concurrent with vacuuming
(Tom Lane)

An index page split caused by an insertion could sometimes cause a
concurrently-running VACUUM to miss removing index entries that it
should remove. After the corresponding table rows are removed, the
dangling index entries would cause errors (such as "could not read block
N in file ...") or worse, silently wrong query results after unrelated
rows are re-inserted at the now-free table locations. This bug has been
present since release 8.2, but occurs so infrequently that it was not
diagnosed until now. If you have reason to suspect that it has happened
in your database, reindexing the affected index will fix things.

Hata kesinlikle budur demiyorum, hatta 8.3.7'den o serideki son sürüm
olan 8.3.19'a kadar en az 6 tane veri bozulması ile ilgili hata
düzeltmesi var. 8.3.7 16 MArt 2009'da, yani 3 yıldan uzun bir süre önce
çıkmış. Keşke arada güncelleseydiniz, o zaman bu dertlerle karşılaşma
durumunuz olmazdı.

Şimdi, eğer index corruption ise, o zaman indexi drop etmeyi
deneyebilirsiniz. Ben olsam şunları yapardım:

* Aynı işletim sistemi (mimarisine kadar) ve 8.3'ün son PostgreSQL
sürümünü yeni bir makinaya kurardım.
* Mevcut verinin snapshot'ını alıp yeni makinaya aktarırdım
* Yeni PostgreSQL'i çalıştırıp, ilgili indexleri drop edip tekrar
yaratırdım.
* Sonra da kontrol ederdim.

Umarım verinizi kurtarırsınız. Bundan sonra da düzenli yedek ve sürüm
güncelleme konusunda daha fazla dikkat edersiniz :-)

İyi çalışmalar,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

index yok ki tabloda. ayrıyeten tabloda copy,select çalışmıyor nasıl
taşıyacak?

12 Temmuz 2012 10:49 tarihinde Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> yazdı:

>
> Merhaba,
>
> On Tue, 2012-07-10 at 08:40 -0700, Uygar UZUNHASAN wrote:
> > INFO: analyzing "public.hareket"ERROR: could not read block 149 of
> > relation 1663/517477/498735: No such file or directory
> > ERROR: could not read block 149 of relation 1663/517477/498735: No
> > such file or directory
> >
> > Merhabalar
> > Postgresql 8.3.7 sürüm (malesef Win server 2003) veritabanı sisteminde
> > veya "hareket" tablosunda vacuum, analyze ve reindex gibi işlemleri
> > yapmaya çalıştığımda, veya adı geçen tabloyu içeren bir sorgu
> > çalıştırdığımda üstteki uyarıyı alıyorum.
>
>
> http://www.postgresql.org/docs/9.1/static/release-8-3-18.html
>
> Fix btree index corruption from insertions concurrent with vacuuming
> (Tom Lane)
>
> An index page split caused by an insertion could sometimes cause a
> concurrently-running VACUUM to miss removing index entries that it
> should remove. After the corresponding table rows are removed, the
> dangling index entries would cause errors (such as "could not read block
> N in file ...") or worse, silently wrong query results after unrelated
> rows are re-inserted at the now-free table locations. This bug has been
> present since release 8.2, but occurs so infrequently that it was not
> diagnosed until now. If you have reason to suspect that it has happened
> in your database, reindexing the affected index will fix things.
>
> Hata kesinlikle budur demiyorum, hatta 8.3.7'den o serideki son sürüm
> olan 8.3.19'a kadar en az 6 tane veri bozulması ile ilgili hata
> düzeltmesi var. 8.3.7 16 MArt 2009'da, yani 3 yıldan uzun bir süre önce
> çıkmış. Keşke arada güncelleseydiniz, o zaman bu dertlerle karşılaşma
> durumunuz olmazdı.
>
> Şimdi, eğer index corruption ise, o zaman indexi drop etmeyi
> deneyebilirsiniz. Ben olsam şunları yapardım:
>
> * Aynı işletim sistemi (mimarisine kadar) ve 8.3'ün son PostgreSQL
> sürümünü yeni bir makinaya kurardım.
> * Mevcut verinin snapshot'ını alıp yeni makinaya aktarırdım
> * Yeni PostgreSQL'i çalıştırıp, ilgili indexleri drop edip tekrar
> yaratırdım.
> * Sonra da kontrol ederdim.
>
> Umarım verinizi kurtarırsınız. Bundan sonra da düzenli yedek ve sürüm
> güncelleme konusunda daha fazla dikkat edersiniz :-)
>
> İyi çalışmalar,
> --
> Devrim GÜNDÜZ
> Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
> PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
> Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
>

Evet, tabloda index yok, ayrıca snapshot alıp aynen dediğiniz gibi başka bir makinaya kurmak da işe yaramıyor çünkü cluster kopyalanırken hata veriyor. Yalnız bir dosyada da değil. Üzerinde çalıştığım veritabanında bir tablo hasarlı iken diğer veritabanlarında da farklı tablolarda benzer hasarlar var.
Üzerinde çalıştığım veritabanında pg_dump -T "hasarlıTabloAdı" şeklinde komut ile yedek almayı başardım ama diğer veri tabanlarında durum daha vahim. pg_dumpall çalışmasa da yalnızca global tabloları "pg_dumpall -g" ile (kullanıcı bilgi ve şifreleri vs) da alabildim. Sanırım bu noktadan sonra postgres sunucuyu kaldırıp temiz bir 8.4 kurmakdan başka yapılacak birşey kalmadı.
Ama son bir kurtarma denemesi için base içinden hasarlı tabloları silsem de "pg_xlog" dan da faydalanarak tabloları kurtarabilir miyim?

>________________________________
> Kimden: Erdinc Akkaya <hz(dot)root(at)gmail(dot)com>
>Kime: Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>
>Kopya: Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>; Postgres Listesi <pgsql-tr-genel(at)postgresql(dot)org>
>Gönderildiği Tarih: 12 Temmuz 2012 11:05 Perşembe
>Konu: Re: [pgsql-tr-genel] ERROR: could not read block 149
>
>
>index yok ki tabloda. ayrıyeten tabloda copy,select çalışmıyor nasıl taşıyacak?
>
>
>12 Temmuz 2012 10:49 tarihinde Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> yazdı:
>
>
>>Merhaba,
>>
>>
>>On Tue, 2012-07-10 at 08:40 -0700, Uygar UZUNHASAN wrote:
>>> INFO:  analyzing "public.hareket"ERROR:  could not read block 149 of
>>> relation 1663/517477/498735: No such file or directory
>>> ERROR:  could not read block 149 of relation 1663/517477/498735: No
>>> such file or directory
>>>
>>> Merhabalar
>>> Postgresql 8.3.7 sürüm (malesef Win server 2003) veritabanı sisteminde
>>> veya "hareket" tablosunda vacuum, analyze ve reindex gibi işlemleri
>>> yapmaya çalıştığımda, veya adı geçen tabloyu içeren bir sorgu
>>> çalıştırdığımda üstteki uyarıyı alıyorum.
>>
>>
>>http://www.postgresql.org/docs/9.1/static/release-8-3-18.html
>>
>>Fix btree index corruption from insertions concurrent with vacuuming
>>(Tom Lane)
>>
>>An index page split caused by an insertion could sometimes cause a
>>concurrently-running VACUUM to miss removing index entries that it
>>should remove. After the corresponding table rows are removed, the
>>dangling index entries would cause errors (such as "could not read block
>>N in file ...") or worse, silently wrong query results after unrelated
>>rows are re-inserted at the now-free table locations. This bug has been
>>present since release 8.2, but occurs so infrequently that it was not
>>diagnosed until now. If you have reason to suspect that it has happened
>>in your database, reindexing the affected index will fix things.
>>
>>Hata kesinlikle budur demiyorum, hatta 8.3.7'den o serideki son sürüm
>>olan 8.3.19'a kadar en az 6 tane veri bozulması ile ilgili hata
>>düzeltmesi var. 8.3.7 16 MArt 2009'da, yani 3 yıldan uzun bir süre önce
>>çıkmış. Keşke arada güncelleseydiniz, o zaman bu dertlerle karşılaşma
>>durumunuz olmazdı.
>>
>>Şimdi, eğer index corruption ise, o zaman indexi drop etmeyi
>>deneyebilirsiniz. Ben olsam şunları yapardım:
>>
>>* Aynı işletim sistemi (mimarisine kadar) ve 8.3'ün son PostgreSQL
>>sürümünü yeni bir makinaya kurardım.
>>* Mevcut verinin snapshot'ını alıp yeni makinaya aktarırdım
>>* Yeni PostgreSQL'i çalıştırıp, ilgili indexleri drop edip tekrar
>>yaratırdım.
>>* Sonra da kontrol ederdim.
>>
>>Umarım verinizi kurtarırsınız. Bundan sonra da düzenli yedek ve sürüm
>>güncelleme konusunda daha fazla dikkat edersiniz :-)
>>
>>İyi çalışmalar,
>>--
>>Devrim GÜNDÜZ
>>Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
>>PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
>>Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
>>http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz
>>
>
>
>

Pg_xlog da en son hangi loglar var? Eger varsa yeniden oynatabilirsin. Diskte sıkıntı olabilir mi? Kontrol ettiniz mi?

Erdinç AKKAYA

On 12 Tem 2012, at 12:43, Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com> wrote:

> Evet, tabloda index yok, ayrıca snapshot alıp aynen dediğiniz gibi başka bir makinaya kurmak da işe yaramıyor çünkü cluster kopyalanırken hata veriyor. Yalnız bir dosyada da değil. Üzerinde çalıştığım veritabanında bir tablo hasarlı iken diğer veritabanlarında da farklı tablolarda benzer hasarlar var.
> Üzerinde çalıştığım veritabanında pg_dump -T "hasarlıTabloAdı" şeklinde komut ile yedek almayı başardım ama diğer veri tabanlarında durum daha vahim. pg_dumpall çalışmasa da yalnızca global tabloları "pg_dumpall -g" ile (kullanıcı bilgi ve şifreleri vs) da alabildim. Sanırım bu noktadan sonra postgres sunucuyu kaldırıp temiz bir 8.4 kurmakdan başka yapılacak birşey kalmadı.
> Ama son bir kurtarma denemesi için base içinden hasarlı tabloları silsem de "pg_xlog" dan da faydalanarak tabloları kurtarabilir miyim?
>
> Kimden: Erdinc Akkaya <hz(dot)root(at)gmail(dot)com>
> Kime: Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>
> Kopya: Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>; Postgres Listesi <pgsql-tr-genel(at)postgresql(dot)org>
> Gönderildiği Tarih: 12 Temmuz 2012 11:05 Perşembe
> Konu: Re: [pgsql-tr-genel] ERROR: could not read block 149
>
> index yok ki tabloda. ayrıyeten tabloda copy,select çalışmıyor nasıl taşıyacak?
>
> 12 Temmuz 2012 10:49 tarihinde Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> yazdı:
>
> Merhaba,
>
> On Tue, 2012-07-10 at 08:40 -0700, Uygar UZUNHASAN wrote:
> > INFO: analyzing "public.hareket"ERROR: could not read block 149 of
> > relation 1663/517477/498735: No such file or directory
> > ERROR: could not read block 149 of relation 1663/517477/498735: No
> > such file or directory
> >
> > Merhabalar
> > Postgresql 8.3.7 sürüm (malesef Win server 2003) veritabanı sisteminde
> > veya "hareket" tablosunda vacuum, analyze ve reindex gibi işlemleri
> > yapmaya çalıştığımda, veya adı geçen tabloyu içeren bir sorgu
> > çalıştırdığımda üstteki uyarıyı alıyorum.
>
>
> http://www.postgresql.org/docs/9.1/static/release-8-3-18.html
>
> Fix btree index corruption from insertions concurrent with vacuuming
> (Tom Lane)
>
> An index page split caused by an insertion could sometimes cause a
> concurrently-running VACUUM to miss removing index entries that it
> should remove. After the corresponding table rows are removed, the
> dangling index entries would cause errors (such as "could not read block
> N in file ...") or worse, silently wrong query results after unrelated
> rows are re-inserted at the now-free table locations. This bug has been
> present since release 8.2, but occurs so infrequently that it was not
> diagnosed until now. If you have reason to suspect that it has happened
> in your database, reindexing the affected index will fix things.
>
> Hata kesinlikle budur demiyorum, hatta 8.3.7'den o serideki son sürüm
> olan 8.3.19'a kadar en az 6 tane veri bozulması ile ilgili hata
> düzeltmesi var. 8.3.7 16 MArt 2009'da, yani 3 yıldan uzun bir süre önce
> çıkmış. Keşke arada güncelleseydiniz, o zaman bu dertlerle karşılaşma
> durumunuz olmazdı.
>
> Şimdi, eğer index corruption ise, o zaman indexi drop etmeyi
> deneyebilirsiniz. Ben olsam şunları yapardım:
>
> * Aynı işletim sistemi (mimarisine kadar) ve 8.3'ün son PostgreSQL
> sürümünü yeni bir makinaya kurardım.
> * Mevcut verinin snapshot'ını alıp yeni makinaya aktarırdım
> * Yeni PostgreSQL'i çalıştırıp, ilgili indexleri drop edip tekrar
> yaratırdım.
> * Sonra da kontrol ederdim.
>
> Umarım verinizi kurtarırsınız. Bundan sonra da düzenli yedek ve sürüm
> güncelleme konusunda daha fazla dikkat edersiniz :-)
>
> İyi çalışmalar,
> --
> Devrim GÜNDÜZ
> Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
> PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
> Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
>
>
>

Az önce kontrol ettim, malesef 8 adet xlog dosyası var, en
eskisi 2 Temmuz. Halbuki bu tablo Ocak ayından beri değiştirilmedi hiç.
Yani sanırım xloglar da bi işe yaramayacak.

 Uygar UZUNHASAN

>________________________________
> Kimden: Erdinc Akkaya <hz(dot)root(at)gmail(dot)com>
>Kime: Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>
>Kopya: Postgres Listesi <pgsql-tr-genel(at)postgresql(dot)org>
>Gönderildiği Tarih: 12 Temmuz 2012 12:46 Perşembe
>Konu: Re: Yan: [pgsql-tr-genel] ERROR: could not read block 149
>
>
>Pg_xlog da en son hangi loglar var? Eger varsa yeniden oynatabilirsin. Diskte sıkıntı olabilir mi? Kontrol ettiniz mi?
>
>Erdinç AKKAYA
>
>
>
>On 12 Tem 2012, at 12:43, Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com> wrote:
>
>
>Evet, tabloda index yok, ayrıca snapshot alıp aynen dediğiniz gibi başka bir makinaya kurmak da işe yaramıyor çünkü cluster kopyalanırken hata veriyor. Yalnız bir dosyada da değil. Üzerinde çalıştığım veritabanında bir tablo hasarlı iken diğer veritabanlarında da farklı tablolarda benzer hasarlar var.
>>Üzerinde çalıştığım veritabanında pg_dump -T "hasarlıTabloAdı" şeklinde komut ile yedek almayı başardım ama diğer veri tabanlarında durum daha vahim. pg_dumpall çalışmasa da yalnızca global tabloları "pg_dumpall -g" ile (kullanıcı bilgi ve şifreleri vs) da alabildim. Sanırım bu noktadan sonra postgres sunucuyu kaldırıp temiz bir 8.4 kurmakdan başka yapılacak birşey kalmadı.
>>Ama son bir kurtarma denemesi için base içinden hasarlı tabloları silsem de "pg_xlog" dan da
faydalanarak tabloları kurtarabilir miyim?
>>
>>
>>
>>
>>>________________________________
>>> Kimden: Erdinc Akkaya <hz(dot)root(at)gmail(dot)com>
>>>Kime: Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>
>>>Kopya: Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>; Postgres Listesi <pgsql-tr-genel(at)postgresql(dot)org>
>>>Gönderildiği Tarih: 12 Temmuz 2012 11:05 Perşembe
>>>Konu: Re: [pgsql-tr-genel] ERROR: could not read block 149
>>>
>>>
>>>index yok ki tabloda. ayrıyeten tabloda copy,select çalışmıyor nasıl taşıyacak?
>>>
>>>
>>>12 Temmuz 2012 10:49 tarihinde Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> yazdı:
>>>
>>>
>>>>Merhaba,
>>>>
>>>>
>>>>On Tue, 2012-07-10 at 08:40 -0700, Uygar UZUNHASAN wrote:
>>>>> INFO:  analyzing "public.hareket"ERROR:  could not read block 149 of
>>>>> relation 1663/517477/498735: No such file or directory
>>>>> ERROR:  could not read block 149 of relation 1663/517477/498735: No
>>>>> such file or directory
>>>>>
>>>>> Merhabalar
>>>>> Postgresql 8.3.7 sürüm (malesef Win server 2003) veritabanı sisteminde
>>>>> veya "hareket" tablosunda vacuum, analyze ve reindex gibi işlemleri
>>>>> yapmaya çalıştığımda, veya adı geçen tabloyu içeren bir sorgu
>>>>> çalıştırdığımda üstteki uyarıyı alıyorum.
>>>>
>>>>
>>>>http://www.postgresql.org/docs/9.1/static/release-8-3-18.html
>>>>
>>>>Fix btree index corruption from insertions concurrent with vacuuming
>>>>(Tom Lane)
>>>>
>>>>An index page split caused by an insertion could sometimes cause a
>>>>concurrently-running VACUUM to miss removing index entries that it
>>>>should remove. After the corresponding table rows are removed, the
>>>>dangling index entries would cause errors (such as "could not read block
>>>>N in file ...") or worse, silently wrong query results after unrelated
>>>>rows are re-inserted at the now-free table locations. This bug has been
>>>>present since release 8.2, but occurs so infrequently that it was not
>>>>diagnosed until now. If you have reason to suspect that it has happened
>>>>in your database, reindexing the affected index will fix things.
>>>>
>>>>Hata kesinlikle budur demiyorum, hatta 8.3.7'den o serideki son sürüm
>>>>olan 8.3.19'a kadar en az 6 tane veri bozulması ile ilgili hata
>>>>düzeltmesi var. 8.3.7 16 MArt 2009'da, yani 3 yıldan uzun bir süre önce
>>>>çıkmış. Keşke arada güncelleseydiniz, o zaman bu dertlerle karşılaşma
>>>>durumunuz olmazdı.
>>>>
>>>>Şimdi, eğer index corruption ise, o zaman indexi drop etmeyi
>>>>deneyebilirsiniz. Ben olsam şunları yapardım:
>>>>
>>>>* Aynı işletim sistemi (mimarisine kadar) ve 8.3'ün son PostgreSQL
>>>>sürümünü yeni bir makinaya kurardım.
>>>>* Mevcut verinin snapshot'ını alıp yeni makinaya aktarırdım
>>>>* Yeni PostgreSQL'i çalıştırıp, ilgili indexleri drop edip tekrar
>>>>yaratırdım.
>>>>* Sonra da kontrol ederdim.
>>>>
>>>>Umarım verinizi kurtarırsınız. Bundan sonra da düzenli yedek ve sürüm
>>>>güncelleme konusunda daha fazla dikkat edersiniz :-)
>>>>
>>>>İyi çalışmalar,
>>>>--
>>>>Devrim GÜNDÜZ
>>>>Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
>>>>PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
>>>>Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
>>>>http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz
>>>>
>>>
>>>
>>>
>
>

On Thu, 2012-07-12 at 11:05 +0300, Erdinc Akkaya wrote:
> index yok ki tabloda. ayrıyeten tabloda copy,select çalışmıyor nasıl
> taşıyacak?

snapshot demiştim?
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

On Thu, 2012-07-12 at 02:43 -0700, Uygar UZUNHASAN wrote:
> Ama son bir kurtarma denemesi için base içinden hasarlı tabloları
> silsem de "pg_xlog" dan da faydalanarak tabloları kurtarabilir miyim?

xloglardan veri kurtarmak için :

* Ya önceden hazırlıklı olmanız gerekli (base backup, vs)

* xlogları dump edebilecek birşeyleri ya yazmanız, ya da kullanabilmeniz
gerekli.

--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

farketmez ki snapshot alsanda tabloda `corruption` var. dosya sistemi
üzerindeki bozuk bir bloğu
farklı bir makinaya aynı şekilde bozuk olarak taşısakta birşey
farketmeyecektir. xloglar yokmuş bu arada.

12 Temmuz 2012 15:08 tarihinde Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> yazdı:

> On Thu, 2012-07-12 at 11:05 +0300, Erdinc Akkaya wrote:
> > index yok ki tabloda. ayrıyeten tabloda copy,select çalışmıyor nasıl
> > taşıyacak?
>
> snapshot demiştim?
> --
> Devrim GÜNDÜZ
> Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
> PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
> Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
>

On Thu, 2012-07-12 at 15:18 +0300, Erdinc Akkaya wrote:
> farketmez ki snapshot alsanda tabloda `corruption` var. dosya sistemi
> üzerindeki bozuk bir bloğu farklı bir makinaya aynı şekilde bozuk
> olarak taşısakta birşey farketmeyecektir.

Galiba ben veriyi kurtarma bakış açısındayım. "Birşey farketmeyeecktir"
ile "deneyelimi, belki milim milim ilerleriz" arasında fark var Erdinç.

Gerçi Uygar Bey de "neyse, 8.4'ü kuralım" demiş -- e madem öyle bir
seçenek vardı, neden uğraştınız? :)

--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

ne bilim abi, belki bi yerinden toparlarız tabloyu diye bakınıyorduk :)

12 Temmuz 2012 15:23 tarihinde Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> yazdı:

> On Thu, 2012-07-12 at 15:18 +0300, Erdinc Akkaya wrote:
> > farketmez ki snapshot alsanda tabloda `corruption` var. dosya sistemi
> > üzerindeki bozuk bir bloğu farklı bir makinaya aynı şekilde bozuk
> > olarak taşısakta birşey farketmeyecektir.
>
> Galiba ben veriyi kurtarma bakış açısındayım. "Birşey farketmeyeecktir"
> ile "deneyelimi, belki milim milim ilerleriz" arasında fark var Erdinç.
>
> Gerçi Uygar Bey de "neyse, 8.4'ü kuralım" demiş -- e madem öyle bir
> seçenek vardı, neden uğraştınız? :)
>
> --
> Devrim GÜNDÜZ
> Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
> PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
> Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
>

>snapshot demiştim?
snapshot denedim, base klasöründeki dosyalar bozuk olduğu için kopyalanmıyor, yoksa daha önce kullandığım bi yöntemdi.

>Gerçi Uygar Bey de "neyse, 8.4'ü kuralım" demiş -- e madem öyle bir seçenek vardı, neden uğraştınız? :)

Backup alamadığım için çok çaresiz kalmıştım ama sorunlu tabloyu hariç tutarak (dökümanları karıştırırken buldum bugün) yedek alabildim, o tablonun da yedeği vardı zaten, o yüzden sorun kalmadı, temiz bir başlangıç yapabilirim artık.

 
Uygar UZUNHASAN

>________________________________
> Kimden: Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>
>Kime: Erdinc Akkaya <hz(dot)root(at)gmail(dot)com>
>Kopya: Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>; Postgres Listesi <pgsql-tr-genel(at)postgresql(dot)org>
>Gönderildiği Tarih: 12 Temmuz 2012 15:23 Perşembe
>Konu: Re: [pgsql-tr-genel] ERROR: could not read block 149
>
>On Thu, 2012-07-12 at 15:18 +0300, Erdinc Akkaya wrote:
>> farketmez ki snapshot alsanda tabloda `corruption` var. dosya sistemi
>> üzerindeki bozuk bir bloğu farklı bir makinaya aynı şekilde bozuk
>> olarak taşısakta birşey farketmeyecektir.
>
>Galiba ben veriyi kurtarma bakış açısındayım. "Birşey farketmeyeecktir"
>ile "deneyelimi, belki milim milim ilerleriz" arasında fark var Erdinç.
>
>Gerçi Uygar Bey de "neyse, 8.4'ü kuralım" demiş -- e madem öyle bir
>seçenek vardı, neden uğraştınız? :)
>
>--
>Devrim GÜNDÜZ
>Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
>PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
>Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
>http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz
>
>
>