What matters for a password is not its length or whether it contains "special characters", but its entropy. The entropy is a measure of "how much unknown" the password is to the attacker. Since we assume the attacker to be overwhelmingly smart, this "how much unknown" reduces to "how much random": the attacker cannot be defeated by wit, but by randomness.
A definition of entropy which is appropriate for cryptography is the following: a password contains n bits of entropy if the attacker, trying potential passwords in optimal order (starting with the most probable of potential passwords), will need an average of 2n-1 tries before hitting the right one. This definition captures non-uniform password distributions; when the password distribution is uniform (all potential passwords have the same probability of having been chosen by the user), then entropy is n bits if there are 2n potential passwords.
Entropy cannot be assessed by looking at a single or even a selection of passwords; it must be computed by analysing the password generation process (and we assume that the super-smart attacker knows everything about that process except the random choices). Elements of that generation process that involve a human brain tend to be hard to estimate, because human minds are no good at randomness and try to replace it with "tricks". For instance, many people tend to believe that "special chars" (like $, %,&, @...) are somehow "more secure" or "more random" than letters. Mathematically, this does not hold.
More on the notion of entropy and its calculation is explained in that answer.
Therefore, if you want your password to resist attackers, then you must make it so that it has entropy n bits, such that 2n-1 exceeds (preferably with some margin) the number of tries (password hashes) that the attacker is ready to make. This threshold depends on several parameters, including the attacker's patience (how long he will be ready to allocate his computing power on the task of breaking a single password) and, ultimately, his budget (which translates to the number of CPU that he will be able to use on that task). Depending on the used hash function, the individual cost of each try can be configured; see this answer for some details.
Changing your password every 30 days has an impact on this analysis only if the attacker's patience was longer than one month. In practice, this is rarely the case: if the attacker has enough budget to devote 200 computers for one full month on breaking your password, then he is probably richer than you, and this raises the question of why he would want to break through your password anyway. On the other hand, password renewal implies more memory effort on your part, so it will incite you to choose "less random" passwords, which is a problem.
Password renewal policies are a firmly entrenched notion in the business of information security; many sysadmins insist on regular renewal, and security frameworks tend to treat it as gospel. This is, however, a kind of traditional dogma that does not really resist analysis, especially in the modern world (frequent password renewal used to be effective, but that was back in the pre-computer era and in a military context, where password storage systems were weak, leaked a lot, and it was assumed that a number of passwords were under enemy control at any point). See this answer for some more food for thought.
- Don't generate passwords with your head; use a computer to get a random password. See this question for guidance.
- For hashing, use a proper password hashing function (typically bcrypt) configured with a high enough iteration count (higher is better, as long as it does not make it too expensive for you to use).
- All other things being equal, it is better to have more randomness in a password than to insist on a password renewal policy. I recommend that you generate a very random password, and stick to it (you can remember a high entropy password if you keep it active for a long time, and type it daily).