There is no repair command. What happened is that your downgrade replaced the version of glibc from a current version to an older version, and all of the other programs on your system that link against glibc (i.e., everything except the packages which were downgraded first) are now unable to find the symbols they need to link and run.
You can repair this system by starting up a rescue system (OpenSUSE 11.1 Live CD, or put the hard disk in another computer), then manually download the correct version of glibc rpm, unpack it, and manually place its files into the broken system.
In fact you can do this from almost any Linux operating system that can mount the filesystem of your server. The main thing you need is the rpm command, but make sure that the version of rpm in the rescue system is new-ish so that it supports the LZMA archive format, which I think was deployed by the time 11.1 was released. The safest way to do this is to use the OpenSUSE / SUSE 11.1 Live CD as the rescue system, and not something weird and old like Ubuntu 8.04 or SUSE 10.
Once you get glibc working again, you can chroot into the broken system and re-try or rollback the downgrade, and if you run into any errors, just exit from the chroot environment, download the needed packages on the host, and unpack them into the guest.
In fact, it may be easier if you boot up an OpenSUSE 11.1 rescue, to just copy all of the files from /usr and /lib64 from the rescue system, into the broken root volume, overwriting all of your core programs with the original versions (glibc, the kernel, Xorg, and so on). But don't overwrite /boot or you'll lose your menu.lst / menu.cfg. And don't overwrite /etc or you'll lose fstab, which is important and probably not broken (but it will break if you overwrite it with the version on the rescue CD).
Note that this isn't guaranteed to work. You will probably want to run zypper up (as root) in the rescue system BEFORE you do this. This will update all the files in /usr and /lib64 to the latest versions from the updates repository prior to putting them on the server. This provides the best probability that everything will work when you boot into the broken system.
Most likely the answer to your question "suse broken?" is probably "yes", but if you're meticulous and know what you're doing, you can still fix it. Convincing the rpm database of the broken system that everything is ok may prove interesting, however.