Padding oracle attacks occur when the attacker is in position to submit encrypted messages and observe the key owner when it tries to decrypt them. The attacker then provides specially crafted messages (based from some piece of the encrypted data that the attacker would love to see decrypted) that decrypt to junk but occasionally decrypt to junk-with-valid-padding; in these cases, the attacker learns some information on the data he is after.
If you are in a context where the defender is a server that computes itself all encryption and decryption, and the encrypted messages cannot be altered by attackers, then the situation explained above does not arise, and padding oracle attacks are irrelevant.
So, in your case, you should be safe from these attacks, provided that indeed malicious people cannot get their hands on your database full of encrypted messages. This raises the question of why you would encrypt the data at all -- normally, you encrypt data to achieve some confidentiality that you could not obtain otherwise. Therefore, encryption on the server makes sense only if attackers are assumed to be able to at least have a look at the database contents. In many situations where attackers can see data, they can also modify the data; and this would bring back the issue of padding oracle attacks, or, more generally, the need for checked integrity.
To put it bluntly, if you encrypt the data but make no effort at maintaining integrity (with a MAC or a nifty authenticated-encryption mode), then you are betting that possible SQL injections attacks on your server will be read-only. It is up to you to decide whether you feel safe enough with that bet.