unable to lock database

The error means the lock file /var/lib/pacman/db.lck is present. pacman creates it at the start of a transaction and removes it at the end, so either another pacman is running right now, or one stopped without cleaning up.

/var/lib/pacman/db.lck

What it does. pacman creates this file when a transaction starts and removes it when the transaction ends.

Watch out. The error means the file exists. Find out whether a pacman is running before deleting it.

What the lock is for

The lock file itself is not damage. It is a note saying a transaction was in progress.

The database lock is the file /var/lib/pacman/db.lck, which exists only while a pacman transaction is in progress, so that two pacman processes cannot write the local database at the same time.

Two processes installing at once would each be rewriting the record of which files belong to which package. Refusing to start is pacman protecting the database, not a bug to work around.

Work through it in this order

Check whether pacman is actually running. If it is, the answer is to wait: a large upgrade can spend a long time downloading before it prints anything new.
not pacmanpgrep -a pacman
pgrep comes from procps-ng, not from pacman. Output means a pacman process exists; no output means none does.
Look for something else that runs pacman. A graphical package manager, an update applet or a scheduled job holds the same lock while it works, and it may not be visible on screen.
Only when nothing is running, remove the file. At that point the lock is left over from a process that no longer exists, and deleting it is the documented way forward.
not pacmansudo rm /var/lib/pacman/db.lck
rm is not pacman, so the explainer has no level for it. Deleting the file while a transaction is genuinely in progress lets a second pacman write the database at the same time as the first. Read the callout below before running it.

Do not start with the deletion. The order above exists because the two causes look identical from the error message, and only one of them is safe to clear.

If it keeps coming back

A lock that reappears every time means something is starting pacman that you are not. The database consistency check is the place to start, since it reads the local database and reports rather than changing anything:

routinepacman -Dk

Checks the local database for consistency. Read-only.

If the interrupted transaction was an upgrade, re-running the upgrade is the normal next step: pacman works out what was already done. See updating Arch Linux.

Common questions

What does unable to lock database mean?

It means /var/lib/pacman/db.lck exists. pacman creates that file while a transaction runs and removes it at the end, so either a pacman is running now or a previous one did not exit cleanly.

Is it safe to delete db.lck?

Only once you have checked that no pacman process is running. If one is, deleting the lock lets a second pacman write the same database at the same time, which is exactly what the lock exists to prevent.

Why does the lock file keep coming back?

Because something is starting pacman that you did not start by hand, such as a graphical package manager or a scheduled update job. Those hold the same lock while they work.