How to get a distinct count of multiple columns

Question

I've done this before and I'll be darned why I can't recall this.
Table with 3 columns with the primary key defined in column a.
Row a b c
num.
1 020 how abc
2 030 why def
3 010 not ghi
4 040 how abc
5 050 yes def
6 060 why def
So what I want is a count of the unique values for columns b and c as if b and c were actually one field.
So the result of the query would be:
Count = 4 unique rows.
Hopefully I'm making some sort of sense. It's a bit much to ask about the number of occurrences of each duplicate value, I'm sure just getting count of the unique rows of the non-indexed rows will be sufficient. Since the query is meant to be universal for multiple columns of numeric and alphanumeric data and can be expanded for multiple columns, I am simply trying to get a basic skeleton that works for an "on the fly" analysis.

Answer 1

Thanks to all of you. I had the idea and just couldn't nail it down. You did it.
All of you understood what I poorly communicated. My apologies for the lack of prep with a table, I was running patches on the system and couldn't dare interrupt it on my laptop and starting Oracle 11 while Micro$lop was patching all sorts of evil code. This is something I'm setting up on my own time so it's a work I'm going to try to be proud of. So there will be plenty of instrumentation and debugging code for timing.
I'd thought of concatenating columns and was worried it wouldn't backport to older Oracle versions (work goes back to 8.1.7) with nulls and other goofy things like long raw fields or lob/clobs plus the other DBs that are at various sites. What I'm trying to do is improve on a crappy data analysis tool SAP provides to use with reporting unique columns. (Basis people could recognize this as DB05). I tried dragging out the SQL that their ABAP/4 language generates from an SQL trace but it was unusable and often dies on internal storage which on most sites is about 4GB per process. Needless to say, the program is wasteful and I'm trying to keep the work on the DB where it belongs and discourage cowboys from doing this in the DB on the fly and at the same time make it simpler for junior members to use while having a semblance of an audit trail.
What I'm trying to do is work out a tool that checks all the crappy secondary indexes that were created by folks who seem to think in ways that are from an alien species not yet speculated about even with the strongest psychedelics. One of them actually decreases performance by a minimum factor of 5. It's not much when it's 5 seconds but when the response time averages about 3 hours beforehand, you can imagine what it was like afterward. In this particular case, the "logic" was that the index needed to be defined by the order of the fields of the select clause. Some myths never die. So it's not easy to work out which ones haven't been used in a long time, so it's down to finding which of the custom ones are actually bad in terms of selectivity. Some of these may have made a little bit of sense when the system was started up, now that some of these have millions of rows instead of a few thousand, thaw tend to expose the flaws in design.
I'm also trying to make this work on multiple DBs such as DB2, MaxDB and (sob) SQL Squealer. The idea is to write this in ABAP code as a utility without the overhead of internal tables in ABAP as some of these tables are many millions of rows and I have to account for the size in memory. (ABAP field sizes in internal memory are generally much larger than the actual DB lengths. so every bit helps!) So I'm trying to create actual SQL on the fly and use it internally without going through the SAP DB interface which limits the type of SQL functions used and all the overhead. It's intended to grab a secondary index and if there are more than 2 fields defined, work it backwards to show unique values for all columns, all columns - 1, all columns - 2 and so on back to the initial column in the index.
Why does this seem important? On Oracle I can generate histograms but those can often screw up SAP. On other DBs, the indexing cardinality is much more important, particularly with DB optimizers that make some odd decisions. So I need evidence I can push to folks who will only understand if there's a plain and simple analysis that explains it (almost) in crayon.
I'm testing null values next (which worked!) but these suggestions all seem to follow the same idea which won't work in ABAP without some serious memory issues. So I'm down to this type of coding:
exec sql.
<dynamically generated true SQL>
end-exec.
rather than using ABAP with their concept of "open SQL" and the DB interface with all the overhead.
RB's suggestion of the UNION ALL wasn't quite what I was looking for BUT it made me think that this would be a nice enhancement for evaluations!
So the candidates that seem to work for what I wanted are as follows:
SQL> SELECT COUNT (MIN (0)) AS distinct_col3_col4_cnt
2 from rb group by b, c;
DISTINCT_COL3_COL4_CNT
7
select count(distinct(b || c)) num_rows from rb;
So thanks also to Frank, APNL and Nimesh for their examples. Now the fun starts as I spec out the processing.