pvck can check LVM metadata, after that consistency is the job of the filesystem. LVM is only about volume management so it doesn't need to care if the space constituting a particular extent is bad since higher level software catches those issues. LVM metadata only takes up the first (optionally also the last sector) of the physical volume anyways.
If just the first and last sectors of a reasonably large PV (such as you'd see in production) just happen to fail simultaneously, you basically have the sh*ttiest luck in the world since that's so astronomically unlikely. Otherwise, if the admin knows multiple sectors of the drive have been failing, most people are alright with just filing such things as this under "hard drive failed permanently and needs to be replaced."
pvck returns an error, you can check to see if your LVM metadata is backed up in
/etc/lvm somewhere. If it is you can do
pvcreate specifying the backup copy to
pvcreate --uuid "<UUID-of-target-PV>" --restorefile <Path-To-Metadata-Backup-File> <path-to-PV-block-device>
pvcreate --uuid "2VydVW-TNiN-fz9Y-ElRu-D6ie-tXLp-GrwvHz" --restorefile /etc/lvm/archive/vg_raid_00000-1085667159.vg /dev/sda2
If the restore doesn't work (for example, if the first sector is bad) you can re-do the above, but set
--metadatacopies 2 (or you might just go straight to doing that) which will attempt to write the metadata to the first and last sectors on the PV. When
pvscan does its thing on boot it will check both places and if it finds metadata it will verify them against a checksum. If the checksum fails on the first sector but succeeds on the last sector you'll get a non-fatal error message.
Kind of manual and a pain, but then again this is part of the reason why people are excited to get a volume management redux with BTRFS. Most of the time it's not really that much of an issue for the reasons derobert mentioned, and because the people who absolutely positively need to ensure continuity of data will usually do RAID and have a backup strategy.