I don't have Ubuntu 16.04 installed anywhere yet, but based on current trends in Linux system layouts, I can make a pretty good guess at what happened here.
The old distinction between /bin and /usr/bin, and the distinction between /lib and /usr/lib has gone away, because it is no longer the case that we have to install systems on disks so small that we might not be able to get the full user environment onto it. That is to say, even a throwaway USB key is large enough these days for the full OS install, so we no longer need to make a distinction between single user mode tools that traditionally lived outside /usr and everything else, which was segregated under /usr somewhere.
Because a lot of software still believes in this distinction — for example, no current Unix or Linux type system has a /local or /share tree parallel to /usr/local or /usr/share, so you can't just get rid of /usr entirely — the common way for modern OSes to blur this old distinction away is to install everything in /usr and then symlink directories like /usr/bin out to /bin. (Or vice versa; it doesn't matter.)
Therefore, what you did with your mv command is blow away /usr, which was probably a symlink to the consolidated OS installation directory on your system. Not only does this replace /usr/bin and such, it also effectively replaces /bin.
In other words, because there was no /usr/local/lib64/bin/bash before you went in with your heavy-handed "fix", there is now no longer a /usr/bin/bash or a /bin/bash.
Solution: Boot your box into rescue mode and restore the /usr tree to its prior state. You might need an existing working Ubuntu 16.04 system as reference to see how it should be restored.
As for your original problem, your mv command never was a good solution. If you want programs living in /usr/local/lib64 to be runnable without an explicit path, add them to your shell's PATH variable. On Ubuntu, this probably means editing ~/.bash_profile.
Since you talk about a lib directory, you probably aren't dealing with executables, but libraries, in which case you probably need to add an entry to /etc/ld.so.conf.d so that directory is added to the global library cache. See man ldconfig for details.
ssh SERVER /bin/dash -iwork? If not, what is the error message? – johnLate Apr 22 '16 at 23:07libc.so. Unless you've a means to run statically-compile binaries to repair the damage, a reinstall or rescue boot would be in order. – thrig Apr 22 '16 at 23:11cdworks. What works, what doesn't work? And copy-paste the exact commands that you typed and the resulting output, don't just say “it doesn't work”. If not, you'll need to log into that machine in a different way. We can't help you with that since we don't know how you've set it up. You may need to access it physically or to use a remote console. – Gilles Apr 23 '16 at 0:09cdworks before I quit my session. But then I can't connect anymore. – Tony DING Apr 29 '16 at 13:24