Page tree
Skip to end of metadata
Go to start of metadata

Sakai 升级一般包括数据库更新,皮肤更新以及自定义代码的更新。

1.0 数据库升级

A database conversion is typically required in order to upgrade from one Sakai version to another. Database conversion scripts - in distinct versions for MySQL and Oracle, respectively - are found in the reference/docs/conversion folder of the release or in our SVN repository.

In the same directory you will also find conversion scripts for earlier Sakai releases. Migration from an earlier version will require the successive application of all intermediate scripts (see the following table). You cannot, for example, move from 2.6.1 to 2.9.0 by applying a single script. You will need to run 6 or 7 scripts all in a row.

(warning) Note for oracle, some of the scripts will leave your indexes in an invalid state because of LONG->CLOB conversion. You will need to run this script to find the invalid/unusable indexes, THEN run the result of this script to alter these indexes.

select 'alter index '||index_name||' rebuild online;' from user_indexes where status = 'INVALID' or status = 'UNUSABLE'; 
-- Run the resulting SQL commands this script generates if any)

(warning) As a general rule, be sure to read through the conversion scripts before applying them. The conversion scripts are generic in the sense that they do not take into account any special customizations you may have made - such as new roles, or the deployment of additional tools or if you are migrating from 2.4.x - and they may complicate your migration with unintended consequences if you execute them blindly.

(minus) For conversions prior to 2.6 please see the 2.8 install guide. Conversions from much older are not very well supported or tested but should still work.


Upgrade Step







Use scripts updated in 2.6.x branch (r65964+). Include fixes for SAK-16751 - Getting issue details... STATUS , SAK-16753 - Getting issue details... STATUS and SAK-16809 - Getting issue details... STATUS . If you are upgrading from 2.5 please review SAK-15597 - Getting issue details... STATUS for an important property setting issue (not a database conversion issue).

2.6.0 to 2.6.x



SAK-16668 - Getting issue details... STATUS : if you upgraded to Sakai 2.6.0 PRIOR to 1 Sept 2009 you must run this conversion to update data types in ASN_MA_ITEM_T and ASN_NOTE_ITEM_T.

2.6.0 to 2.6.x



SAK-17219 - Getting issue details... STATUS , SAK-16548 - Getting issue details... STATUS : Matt Jones (UMich) reports that the original 2.6.0 to 2.6.1 conversion script for the assignment_content table "is inefficient, potentially locks tables and performs too many scans, especially if there are hundreds of thousands of rows." Matt has revised both the MySQL and Oracle conversion scripts to improve their performance.

2.6.0 to 2.6.x



SAK-16847 - Getting issue details... STATUS : adds asn.share.drafts to SAKAI_REALM_FUNCTION.

2.6.0 to 2.6.x



SAK-10512 - Getting issue details... STATUS : updates existing entries in SAKAI_PERSON_T setting the field locked to false if currently NULL.

2.6.0 to 2.6.1



Rollup of 2.6.0-2.6.x conversion scripts 001-004 above.

2.6.1 to 2.6.2



no schema changes

2.6.0 to 2.6.x



SAK-14482 - Getting issue details... STATUS : replace the "mercury" site's sakai.assignment tool (deprecated since 2.5.0) with the sakai.assignment.grades tool.
















2.7.1 to 2.8.0 database conversion.




Starting up sakai-2.8.0 in order to populate an empty database (auto.ddl=true) can result in certain tools relying on Hibernate to generate indexes to fail to do so. Check database and then run this script to add missing indexes.

2.8.1sakai_2_8_0-2_8_1_mysql_conversion.sqlsakai_2_8_0-2_8_1_oracle_conversion.sqlConversion from 2.8.0 to 2.8.1 can result in lost mail messages. See SAK-21305 - Getting issue details... STATUS for details on how to fix.This should only affect cases for which 2.8.0 was actually RUN in production, not if 2.8.0 is just one step in your upgrade process.
2.9.0sakai_2_9_0_mysql_conversion.sqlsakai_2_9_0_oracle_conversion.sqlFor languages other than English, Catalan and Spanish please see SAM-787 - Getting issue details... STATUS .






LTI 2_1_0_mysql_conversion.sql







10.0sakai_10_mysql.sqlsakai_10_oracle.sqlPlease note, the Oracle conversion scripts should be taken from trunk at the moment, including for the conversion to 10.0 - Neal Caidin - 14-October-2014
10.2no conversion needed for MySqlsakai_10_1-10_2_oracle_conversion.sql 
10.3no conversion needed for MySqlsakai_10_2-10_3_oracle_conversion.sql 
10.4no conversion needed for MySqlno conversion needed for Oracle 

2.0 其它数据库升级


2.1邮件存档 (2.5 -> 2.6)

SAK-13584 - Getting issue details... STATUS , SAK-16554 - Getting issue details... STATUS : Sakai 2.6 improvements to the Message API require that implementers upgrading from a pre-2.6 version of Sakai run both the 2.6.0 conversion scripts and a second script that can be found in the mailarchive module in order to update your existing mail archive data to take advantage of the 2.6 Email Archive performance improvements.
-- SAK-13584 Further Improve the Performance of the Email Archive and Message API. Note you have to run a bash conversion script on your old mail archive data for it to
-- appear in the new mail archive. The script is in the source as Please see the SAK for more information on this script or SAK-16554 for
-- updates to this script.
 	  	        SUBJECT                   ASC
 	  	        SUBJECT           VARCHAR (255) NULL,
	  	        BODY              LONGTEXT NULL

2.2 作业工具 (2.4之前版本)

(warning) This conversion was a part of the post-2.4 assignments branch so those migrating from a version already running this can disregard this step.

SAK-11821 - Getting issue details... STATUS : The assignment service previously permitted the creation of duplicate submission objects (i.e. two or more submissions for the same student and assignment). While the UI should prevent this from happening, at various stages in the evolution of the Assignments code, bugs, race conditions or other failures have led to duplicate objects being created. This conversion seeks to reconcile those duplicates and add database constraints to prevent this is the future.

In summary, the conversion script is necessary to

  1. Remove existing duplicate submission records, if any
  2. Prevent future submission duplicates by applying unique constraint on the ASSIGNMENT_SUBMISSION table
  3. Improve performance of the Assignment tool

The conversion script does the following to the existing ASSIGNMENT_SUBMISSION table in Sakai database:

  1. read in all tuples as AssignmentSubmission object, parse out data such as submitter_id, submit_time, submitted, and graded, and stores those attributes as separate columns in the ASSIGNMENT_SUBMISSION table;
  2. Runs though the table, combine and remove submission duplicates (tuples with same "context" and "submitter_id" combination);
  3. apply the unique constraint of "context" + "submitter_id" to ASSIGNMENT_SUBMISSION table.

There is a README file with detailed instructions on this process at

2.3 文件存储 (2.4 -> 2.5)

Migrating from 2.4 to 2.5 requires adding several columns to the database tables used by the Content Hosting Service (the service used by the Resources tool, Dropbox, filepicker and WebDAV). The conversion scripts contain DDL statements to accomplish those changes. You need to run these conversions scripts (or perform the equivalent operations manually) and then convert your existing Resources via one of the methods outlined below, before you will gain the performance improvements Sakai 2.5 offers.

The new columns added to the database tables support a switch from XML serialization to "binary-entity" serialization, and enable Resources to perform faster and use less memory. One of the key areas this impacts is improving the performance of quota calculations.

There are two methods for converting existing Resources, with the first being the recommended option, as it enables all performance improvements when completed:

  1. Run the conversion utility, which can be run on a live system. (See readme for more details.)
    • (warning) Systems running oracle should read the email threads copied to the comments section below.
  2. Let the code convert each Resource as it is accessed.
    • (warning) This is only recommended for implementations with small datasets, such as pilot deployments; otherwise you should use the above conversion utility.
    • (warning) While some performance benefits from the binary-entity serialization can be realized immediately using this method, others, such as the quota calculation improvements will not be available until all Resources have been accessed and converted.

Based on the state of the data in the Content Hosting Service tables, it will start up in one of two modes:

  1. Binary only - If the code detects on start-up that all of the XML fields are null – as would be the case after running the conversion utility – it will run in binary mode. The means the system will only read and write using binary-entity serialization, and you will be able to fully realize all the performance enhancements that it offers.
  2. Dual mode - If the code detects there is still data in the XML fields – as would be the case if the conversion utility has not be run – it will run in dual mode. This means the system will be capable of reading both XML-serialized and binary-entity-serialized resources, but will write using only binary, and will convert any XML data it encounters into binary data. This gives you some of the performance benefits of binary-entity serialization without running the conversion utility, but you will never get the quota-calculation improvements unless all Resources end up converted.

3.0 学档 (OSP) 权限设置 (2.5之前版本)

OSP was turned off by default in Sakai 10 and removed entirely in Sakai 11.

SAK-13205 - Getting issue details... STATUS : if you are upgrading from a pre-2.5.0 version of Sakai, then you need to force conversion of the OSP permissions by setting osp.upgrade25=true in your file. (See also discussion.)

4.0 Sakai 10 中移除了 链接工具

5.0 升级 Sakai 皮肤



  • No labels