In scheme, you can understand a variable as holding a reference to a value. In the first case a holds a reference (call it RA) to a cons pair <RA0:1, RA1:2> (the car and cdr of the cons pair also hold references to values - in this case I'm calling RA0 the reference to 1, and RA1 the reference to 2). When you fetch a for whatever operation, you receive that reference
That b, in the first example, holds a reference to a pair <RA,RA>. Changing a doing something like (set! a 10) will only change a to be bound to some other reference, which refers to 10, but RA will remain the same. When you fetched in your example 1 a to make b, you got the reference a held at that moment.
When you do (set-car! (car b) 3), what you're doing is pretty much setting the car of the value RA refers to. When you do so, RA still refers to the same cons pair, however, that cons pair now changed. If you look at a, it stills holds the refence <RA> (you haven't changed the reference a is bound to), so if you get its car, you'll get the car of the cons pair RA refers to, which is 3 now. RA, now, refers to something like this <RA2:3, RA1:2>. Notice that the reference car of a holds changed, it was something which refered to 1, now it's something which refes to 3.
If, instead, you did something like you did in the second case, (define x 1) will make x hold a reference, say RX1, which refers to the value 1. When you construct b and a in terms of x, what you're getting is the reference x holds, RX1. So, when you (set! x 3), what you're doing is not changing the value RX1 refers to. You're changing x to be bound to a new reference, something like RX2, which referes to 3.
The set!ish procedures normally do this. They'll change the reference something holds. (set-car! A B) will change the car of A to be bound to a new reference which B specifies; (set! A B) will set A to hold a reference B specifies, and so forth. Of course that's not a universal rule, since you can program your own set!ish functions to do whatever you want.
This model is somewhat like java's with class types. A variable of a class type in java holds a reference to an object, not the object. When you pass a class type variable to a method, you copy its value (i.e. the reference). Not only then, but pretty much all the time afaik, whenever you use a variable for its value in java, you'll get the reference it holds, given the variable is of a class type (interface type, enum type are included too; in java these things are called reference types iirc). Assigning to a variable, doesn't change the object it held, but only changes the reference in the variable (i.e. the object it refers to). If you put Object a = ...; list.add(a); a = somethingElse; the object added to list will remain unaltered.
This is a different model from C's, for example, in which variables name direct store for the values.
I think _javascript_, python and ruby follow the same kinds of rules scheme does for this sort of thing.
A somewhat related issue with this is that this model (scheme's) makes things look like pass-by-reference, even though scheme always does pass-by-value.