Database programmers do many things. First they design the database structure so that it will perform properly with the number of expected records. Design structures that work OK for a few thousand records can make a database unusable at a few million records.
They also need to make sure the data will maintain it's integrity over time and that the data is secure from unauthorized changes or theft. They have to throughly understand normalization and when to denormalize and why. They have to understand performance and how to ensure data integrity. They have to understand security and how to prevent data from being stolen or maliciously changed.
They performance tune queries. I have changed queries that take minutes to run to millseconds. I have changed a process that took over 24 hours to run to less than 30 minutes. They design and maintain indexing structures that will balance the speed of inserts against the speed of selects.
They write complex queries especially reporting queries. I personally have written queries that are over 1000 lines long due to the complexity of the requirement. They still had to and did run quickly.
They create data warehouses and the accompanying ETL processes to support them. Often they need to write processes to bring data in from other sources and have to figure out how to map the fields from some clients data base to theirs and these are never a close match in data type, data size, required fields, lookup values, etc.
They have to determine how to refactor as the database requirements change without harming the 100,000,000 records they already have and without bring the usage of the database to a complete halt. Large databses can involve thousands of tables and stored procs and user-defined functions. Understanding such a structure takes time and skill as does understanding what will be impacted by changes and how.
They design ways to audit the data for regulatory and recovery reasons. They then design ways to recover the data from those audit tables. They research problems with the data to find if the problem was from a bug in the import process, a bad file provided by others or a bad insert/update from the application, or from unauthorized access. They find ways to fix the bad data when the application programmers left open a hole for hackers to attack.
Often they are involved in data conversions from one system to a new system. Sometimes this involves moving data from one COTS product to a new one that the company just purchased. Like the imports described earlier, these are complex processes which can take months to plan for and execute and which require extensive testing. Unlike the imports, the database programmer may have no control over the disparate data structures.