Skip to main content
Blackboard Help

Understanding the Database Schema

Database Schema Naming

Database schema names have received a re-work for this latest version of Blackboard Learn. When upgrading an existing instance, or creating a testing environment for an institution using the legacy database schema names, please refer to the following table. Manual database schema name changes on an existing schema should only be done with the assistance of Blackboard support. Legacy environments should specify the legacy information within the database identifier option in the installer when creating testing environments.

Schema Name Legacy Schema Name

The Database Statistics Schema

The activity_accumulator_cr procedure has been modified to insert new records into the new table activity_accumulator_queue instead of directly into the activity_accumulator table. The new table will be smaller in size, which reduces the performance impact of activity_accumulator_cr, which runs for every user action. Use of indexes on activity_accumulator_queue table should be avoided in the interest of application performance.

A job has been scheduled via the Oracle DBMS_JOB interface to run a stored procedure activity_accumulator_update which flushes the queue table every 10 minutes into the actual activity_accumulator. The activity_accumulator_update copies data from the queue table to activity_accumulator, which is the production table that holds the data permanently. This job inserts data in 2000-record batches to the activity_accumulator (though it leaves between 500-2000 records behind each time). Between the hours of 23:00 and 00:00 each night, database time, the job moves a higher volume of data to clean up any missed records from previously.

The activity_accumulator table contains attendance/activity data which is used by many institutions as part of grading information, and is thus among the most important data in the database. It is crucial that this table be recoverable in the event of media failure. Though the insertion and deletion are performed at the same time, with the insert taking place first, the data is still available in the queue table and available for the next push should a rollback be required. Given the importance of this data, logging is enabled should an incident occur in an incorrectly configured Database or other disaster recovery need arise.

The PurgeAccumulator job is unchanged and still runs at 1:00 am every day to perform its three functions of summarize (system tracking), synchronize (BBLEARN to BBLEARN_STATS), and purge (BBLEARN). To learn more, see PurgeAccumulator.

Note:  If the Oracle parameter job_queue_processes is set to zero, the activity_accumulator_update job will not run. As a symptom, the system tracking pages would start showing zeros and course activity reports would show no activity.