This is a very good question.
First, note that subversion uses a db database with only a few files, not one file per file in the repository, unless you're using the new FSFS backend, with which I am not completly familair.
It would be nice if subversion kept a md5sum or something of what should be in the repository database files so it could detect small changes due to disk problems. Then you could detect repository breakage immediatly instead of continuing to use a broken repository. Unfortunatly, it does not do this.
What it does do is keep a md5 checksum of each revision of each file in the repository. It checks these checksums at various points during updates and so on, so if a file in your working copy gets corrupted it will detect that. And it will detect if a disk problem corrupts the content of a file stored in the repository. For example:
svn: Checksum mismatch on rep '1':
So I don't consider svn's checksum coverage to be complete, but I am sure that I'm getting out the same files that I checked in. To protect against general repository corruption that is not caught by subversion's internal checks, you need to do backups of your repository, preferably using something like svnadmin dump or hot-backup.
Personally, I do offsite incremental backups of my svn repository using duplicity; these end up gpg encrypted and sha1-summed, and are written to reliable media.