The requirements for an IV depend on which encryption algorithm you are using (AES is not an encryption algorithm by itself, since it can only act on 16-byte strings, but it can be used as a building block in a variety of different encryption schemes), specifically on the mode of operation.
Roughly speaking, the role of the IV is to insert some "new" randomness into the process each time a message is encrypted. That way, the same message encrypts to a different ciphertext each time, and similar messages to not result in similar ciphertexts. This is the reason why IVs often need to be random, but never need to be secret.
To answer your questions:
IVs do not need to be secret. In fact, they are often considered part of the ciphertext, and it is assumed that in adversary will see them.
Predictable IVs can sometimes be harmful. If you are using AES inside of Counter mode (CTR) encryption, predictable IVs are fine (the IV acts as a counter that gets incremented with each 16-byte block you encrypt; the important point here is that a counter value should never be repeated). On the other hand, if you are using Cipher Block Chaining mode (CBC), a predictable IV can allow some chosen-plaintext attacks. Preventing this is usually considered the ideal goal of an encryption scheme, since it implies the attacker can't do other, more harmful, things. Depending on the specific context, predictable CBC IVs can definitely cause problems.
Hashing doesn't necessarily make IVs more unpredictable. Hashing an otherwise predictable IV can make it look "more random", but where are you getting the salt and pepper? If these are also predictable, then hashing hasn't gained you anything. If they are random, then why not use this random number generator to make your IV directly?
You can play it safe by always generating random IVs. This can be "overkill" for algorithms such as CTR mode, but it will still be safe.
For more information:
Based on my understanding of what you're doing (I'm not to clear on the details), I'd recommend that whenever you update or create a row, generate a new, random IV for that row, and then use that IV for the encryption. The IV can be concatenated to the ciphertext, or stored in a separate location.
If storing IVs is impractical, a better alternative to hashing would be to use a second key $K$ to generate IVs; for example, the IV for row i could be $\textrm{AES}_K(i)$ or $\textrm{HMAC-SHA256}_K(i)$. The reason for this is that hash functions are not the same thing as pseudo-random functions from a cryptographic perspective, and so hashing something doesn't really give you a random IV. This approach is not secure if you need to update rows (or rather, if an adversary could potentially see two different ciphertexts for the same row), since repeating an IV is bad, bad, bad.
