The standard way is to put the credentials into a config file, and attempt to protect the config file from being more readable than the perl file. This offers a moderate increase in security; for example, the code may be in source control and accessible to developers, the config file wouldn't be. The code needs to be in the web server's cgi root, and possibly downloadable under certain misconfigurations, and the config file needn't be.
The ambitious way is to reversibly encrypt the credentials and put them into a config file. Of course, anything reversibly encrypted can be decrypted. The BladeLogic application did this, and it was trivial (<1 day) for me to de-compile their Java enough to find out the function to decrypt credentials and use it to decrypt them to my satisfaction. Not a mark against them; that's just the name of the reversibly encrypted game.
Another option is to use OS-based authorization in concert with strictly limited database restrictions. For example, limit the database client user's access to a set of stored procedures to limit the potential for abuse, and allow that user to access the database without a password. This doesn't work if you're doing client-server over the network, which limits how often it's useful. Also, people tend to look more askance at "passwordless" OS-user access than they do at writing the password down willy-nilly. It is not completely logical, but there are standards that say all database users must have passwords, so that's that.