Suppose, you have a special log table of your application.
What do you think about creating a BLOB field for a possible stack trace ?
Logging is done to file as well, but it is not so convenient to read a text file, moreover database is more "accessible".
What if the stack trace is due to a database connection failure? Some things need to be as low-level and simple as possible. Also, I don't see why a database should be any more or less accessible than a file share or ssh account.
I previously worked on an application where this happened, but as Marcelo Cantos suggests, it was never really reliable because certain exceptions couldn't be logged there, so we never used it and always relied on log files instead.
If you use the log file to debug errors, you'll also get any other debug of info messages you choose to print, in the correct order; it's rare that all you need is a stack trace, usually what led up to the stack trace is equally if not more useful.
Duplicate logging sounds like... well, duplicate logging. Overhead. If you need to access the logs through database, I would rather use/write a tool that can import the logs to a separate database when needed. Or make them accessible by some other means. One tool that I know of is Splunk, but it's expensive and I'm sure there are others too.
Why ? Or at least, if you're going to do it, why the Blob field ?
If I were to implement something like this, I would separate the exceptions into separate StackTraceElements and store those into a proper table. Over time and a variety of failures, you might generate some interesting statistics about the nature of risk and quality within your application.