Thread: Errors after cloning OS to new disk under Hyper-V
Hello,
This is PostgreSQL v10.10 64Bit, running on Windows 10 64Bit.
One user, by himself, without asking for help, cloned his OS from one disk to Hyper-V disk. Old disk was not accessed,
OSwas shutdown while he is doing the cloning. He used some kind of tool that I do not know for that purpose. New server
isrunning under Hyper-V.
Once he saw Hyper-V server is up and running he deleted old disk for good. Unfortunately, new system has more than
briefproblems. He has no backup of the database cluster or particular database(s) in it.
I see in log following errors:
2020-07-16 12:28:17.598 +03 [3964] HATA (ERROR): "pg_opclass_oid_index" indeksinde 0 bloğunda beklenmeyen boş sayfa
2020-07-16 12:28:17.598 +03 [3964] İPUCU:Lütfen onu REINDEX'leyin.
2020-07-16 12:29:02.065 +03 [2744] LOG: istemciden veri alınamamıştır: unrecognized winsock error 10054
2020-07-16 12:29:17.699 +03 [3748] HATA (ERROR): "pg_opclass_oid_index" indeksinde 0 bloğunda beklenmeyen boş sayfa
2020-07-16 12:29:17.699 +03 [3748] İPUCU:Lütfen onu REINDEX'leyin.
2020-07-16 12:30:17.805 +03 [1456] HATA (ERROR): "pg_opclass_oid_index" indeksinde 0 bloğunda beklenmeyen boş sayfa
2020-07-16 12:30:17.805 +03 [1456] İPUCU:Lütfen onu REINDEX'leyin.
2020-07-16 12:30:47.363 +03 [7460] ÖLÜMCÜL (FATAL): base/16394/2684 nesnesinin 0 bloğunda geçersiz sayfa
2020-07-16 12:31:04.009 +03 [1240] ÖLÜMCÜL (FATAL): base/16394/2684 nesnesinin 0 bloğunda geçersiz sayfa
2020-07-16 12:31:11.261 +03 [2396] ÖLÜMCÜL (FATAL): base/16394/2684 nesnesinin 0 bloğunda geçersiz sayfa
Basic translation to English is:
ERROR: "pg_opclass_oid_index" index 0 block unexpected empty page
HINT:Please REINDEX it.
LOG: cannot read fata from client: unrecognized winsock error 10054
FATAL: base/16394/2684 object 0 block invalid page
When I try to connect server on command line using psql I get same error:
PS C:\Program Files\PostgreSQL\10 - Kopya\bin> .\psql.exe -U postgres
psql: ÖLÜMCÜL (FATAL): "pg_opclass_oid_index" indeksinde 0 bloğunda beklenmeyen boş sayfa
İPUCU: Lütfen onu REINDEX'leyin.
PS C:\Program Files\PostgreSQL\10 - Kopya\bin> .\psql.exe -U postgres -h localhost
psql: ÖLÜMCÜL (FATAL): "pg_opclass_oid_index" indeksinde 0 bloğunda beklenmeyen boş sayfa
İPUCU: Lütfen onu REINDEX'leyin.
I am told that some databases in cluster can be accessed, not all. They are accessed from an application and not by
admintools. I do not know how many databases exists in the cluster or their names.
I have tried to dump everything and that also failed:
PS C:\logs> & 'C:\Program Files\PostgreSQL\10 - Kopya\bin\pg_dumpall.exe' -f dump.bak -U postgres
pg_dump: [arşivleyici (db)] sorgu başarısız oldu: HATA (ERROR): base/16394/2684 nesnesinin 0 bloğunda geçersiz sayfa
pg_dump: [arşivleyici (db)] sorgu şu idi: SELECT pg_catalog.set_config('search_path', '', false)
pg_dumpall: pg_dump "ZEntegre" veritabanında başarısız oldu, çıkılıyor
I wonder if there is anything that can be done here.
Thanks & Regards,
Ertan
On 7/17/20 8:51 PM, ertan.kucukoglu@1nar.com.tr wrote:
> Hello,
>
> This is PostgreSQL v10.10 64Bit, running on Windows 10 64Bit.
>
> One user, by himself, without asking for help, cloned his OS from one disk to Hyper-V disk. Old disk was not
accessed,OS was shutdown while he is doing the cloning. He used some kind of tool that I do not know for that purpose.
Newserver is running under Hyper-V.
>
> Once he saw Hyper-V server is up and running he deleted old disk for good. Unfortunately, new system has more than
briefproblems. He has no backup of the database cluster or particular database(s) in it.
>
> I see in log following errors:
> 2020-07-16 12:28:17.598 +03 [3964] HATA (ERROR): "pg_opclass_oid_index" indeksinde 0 bloğunda beklenmeyen boş sayfa
> 2020-07-16 12:28:17.598 +03 [3964] İPUCU:Lütfen onu REINDEX'leyin.
> 2020-07-16 12:29:02.065 +03 [2744] LOG: istemciden veri alınamamıştır: unrecognized winsock error 10054
> 2020-07-16 12:29:17.699 +03 [3748] HATA (ERROR): "pg_opclass_oid_index" indeksinde 0 bloğunda beklenmeyen boş sayfa
> 2020-07-16 12:29:17.699 +03 [3748] İPUCU:Lütfen onu REINDEX'leyin.
> 2020-07-16 12:30:17.805 +03 [1456] HATA (ERROR): "pg_opclass_oid_index" indeksinde 0 bloğunda beklenmeyen boş sayfa
> 2020-07-16 12:30:17.805 +03 [1456] İPUCU:Lütfen onu REINDEX'leyin.
> 2020-07-16 12:30:47.363 +03 [7460] ÖLÜMCÜL (FATAL): base/16394/2684 nesnesinin 0 bloğunda geçersiz sayfa
> 2020-07-16 12:31:04.009 +03 [1240] ÖLÜMCÜL (FATAL): base/16394/2684 nesnesinin 0 bloğunda geçersiz sayfa
> 2020-07-16 12:31:11.261 +03 [2396] ÖLÜMCÜL (FATAL): base/16394/2684 nesnesinin 0 bloğunda geçersiz sayfa
>
> Basic translation to English is:
> ERROR: "pg_opclass_oid_index" index 0 block unexpected empty page
> HINT:Please REINDEX it.
> LOG: cannot read fata from client: unrecognized winsock error 10054
> FATAL: base/16394/2684 object 0 block invalid page
>
> When I try to connect server on command line using psql I get same error:
> PS C:\Program Files\PostgreSQL\10 - Kopya\bin> .\psql.exe -U postgres
> psql: ÖLÜMCÜL (FATAL): "pg_opclass_oid_index" indeksinde 0 bloğunda beklenmeyen boş sayfa
> İPUCU: Lütfen onu REINDEX'leyin.
>
> PS C:\Program Files\PostgreSQL\10 - Kopya\bin> .\psql.exe -U postgres -h localhost
> psql: ÖLÜMCÜL (FATAL): "pg_opclass_oid_index" indeksinde 0 bloğunda beklenmeyen boş sayfa
> İPUCU: Lütfen onu REINDEX'leyin.
>
> I am told that some databases in cluster can be accessed, not all. They are accessed from an application and not by
admintools. I do not know how many databases exists in the cluster or their names.
>
> I have tried to dump everything and that also failed:
> PS C:\logs> & 'C:\Program Files\PostgreSQL\10 - Kopya\bin\pg_dumpall.exe' -f dump.bak -U postgres
> pg_dump: [arşivleyici (db)] sorgu başarısız oldu: HATA (ERROR): base/16394/2684 nesnesinin 0 bloğunda geçersiz
sayfa
> pg_dump: [arşivleyici (db)] sorgu şu idi: SELECT pg_catalog.set_config('search_path', '', false)
> pg_dumpall: pg_dump "ZEntegre" veritabanında başarısız oldu, çıkılıyor
>
> I wonder if there is anything that can be done here.
>
> Thanks & Regards,
> Ertan
>
>
>
Have you tried to REINDEX as suggested?
-----Original Message----- From: Rob Sargent <robjsargent@gmail.com> Sent: Saturday, July 18, 2020 5:56 AM To: pgsql-general@lists.postgresql.org Subject: Re: Errors after cloning OS to new disk under Hyper-V > Have you tried to REINDEX as suggested? I cannot get access to psql. If there is a way to reindex without having to login first, I do not know how to do that.
so 18. 7. 2020 v 6:36 odesílatel <ertan.kucukoglu@1nar.com.tr> napsal:
-----Original Message-----
From: Rob Sargent <robjsargent@gmail.com>
Sent: Saturday, July 18, 2020 5:56 AM
To: pgsql-general@lists.postgresql.org
Subject: Re: Errors after cloning OS to new disk under Hyper-V
> Have you tried to REINDEX as suggested?
I cannot get access to psql. If there is a way to reindex without having to login first, I do not know how to do that.
you should to run postgres in single-user mode
postgres --single -D /usr/local/pgsql/data other-options my_database
<ertan.kucukoglu@1nar.com.tr> writes:
> From: Rob Sargent <robjsargent@gmail.com>
>> Have you tried to REINDEX as suggested?
> I cannot get access to psql. If there is a way to reindex without having to login first, I do not know how to do
that.
The disaster recovery process that Rob is suggesting goes like this:
* Shut down server, if it's running
* Start a standalone backend with the -P (disable system indexes) switch:
postgres --single -P database_name
* REINDEX everything in sight, or at least REINDEX SYSTEM
* Quit standalone backend (control-D on Unix, less sure about Windows)
* Repeat for each database you care about
* Restart server
TBH, though, I have no expectation that this will help you. It can
work for fixing a situation with limited damage to system catalog
indexes; but it cannot fix damage to the catalog tables themselves.
Given that the damage seems to have been done by a faulty filesystem-level
copying tool, there's little reason to hope that only the indexes and
not the tables were damaged. No non-Postgres-specific tool would be
likely to know the difference, because they're all just files.
But, having said that, the error messages you quoted seem to be
complaining only about indexes. Maybe it's worth trying this.
Failing that, you could call in a professional data recovery
consultant, if the data is valuable enough for that to make sense.
But this sort of situation is not likely to be recoverable
without detailed expert help, and maybe not then. (A word of
advice: if calling in outside help is even faintly possible,
don't do *anything* without first making a filesystem-level
backup that you can trust. Otherwise your own attempts might
just break things beyond the last chance of repair.)
regards, tom lane