方素正窩: 4月 2009

InnoDB做為MySQL目前最廣泛的事務存儲引擎，很多地方的設計和Oracle都是共通的。對於Oracle DBA來說，學習的時候可以多和Oracle的一些特性進行類比，當然也要明白二者之間的區別。
innodb_additional_mem_pool_size
用於緩存InnoDB數據字典及其他內部結構的內存池大小，類似於Oracle的library cache。這不是一個強制參數，可以被突破。
innodb_buffer_pool_size
內存緩衝池大小，用於緩存表和索引數據等。類似於Oracle的buffer cache，如果可能，盡可能的設置大一點。
innodb_log_buffer_size
日志緩衝區大小，類似於Oracle的log buffer
innodb_log_file_size
日志文件大小。默認會創建2個5M大小的名為ib_logfile0和ib_logfile1的文件。日志文件的數目由參數innodb_log_files_in_group指定。存放位置由innodb_log_group_home_dir指定。
innodb_data_file_path
指定InnoDB表空間數據文件名，大小以及其他屬性。所有文件的加起來不能少於10M。多個數據文件之間以逗號分割，屬性之間以冒號分割。默認創建一個大小10MB名為ibdata1的可自動擴展的數據文件，一般在生產環境中都需要根據實際情況指定，由於往表空間中添加數據文件需要停機，盡量在規劃的時候做好準備，如果可以的話最好開啟最後一個數據文件的自動增長屬性。數據文件的個數在規劃的時候還需要考慮另外一個 innodb_open_files參數。
innodb_file_per_table
取值為ON或者OFF。是否為每個table使用單獨的數據文件保存。如果係統中表的個數不多，並且沒有超大表，使用該參數可以使得各個表之間的維護相對獨立，有一定的好處。
innodb_autoextend_increment
當自動擴展表空間被填滿之時，每次擴展空間的大小，默認值是8(單位MB)。該參數可以動態修改：

以下為引用的內容：
mysql> set global innodb_autoextend_increment=10;
Query OK, 0 rows affected (0.01 sec)
innodb_status_file
定期將show inndb status的結果輸出保存到文件中，建議開啟以便分析性能。
下面是windows上一個MySQL默認的參數查詢結果：
以下為引用的內容：
mysql> show variables like 'Innodb%';
------------------------------------------------

Variable_name　 Value　　　　　　　

------------------------------------------------

innodb_additional_mem_pool_size 2097152　　　　　　　　

innodb_autoextend_increment　　 8　　　　　　　　　　　

innodb_buffer_pool_awe_mem_mb　 0　　　　　　　　　　　

innodb_buffer_pool_size　　　　 8388608　　　　　　　　

innodb_checksums　　　　　　　　 ON　　　　　　　　　　

innodb_commit_concurrency　　　 0　　　　　　　　　　　

innodb_concurrency_tickets　　　 500　　　　　　　　　　

innodb_data_file_path　　　　　 ibdata1:10M:autoextend

innodb_data_home_dir　　　　　　　　　　　　　　　　　　

innodb_doublewrite　　　　　　　 ON　　　　　　　　　　

innodb_fast_shutdown　　　　　　 1　　　　　　　　　　　

innodb_file_io_threads　　　　　 4　　　　　　　　　　　

innodb_file_per_table　　　　　 OFF　　　　　　　　　　

innodb_flush_log_at_trx_commit　 1　　　　　　　　　　　

innodb_flush_method　　　　　　　　　　　　　　　　　　

innodb_force_recovery　　　　　 0　　　　　　　　　　　

innodb_lock_wait_timeout　　　　 50　　　　　　　　　　

innodb_locks_unsafe_for_binlog　 OFF　　　　　　　　　　

innodb_log_arch_dir　　　　　　　　　　　　　　　　　　

innodb_log_archive　　　　　　　 OFF　　　　　　　　　　

innodb_log_buffer_size　　　　　 1048576　　　　　　　　

innodb_log_file_size　　　　　　 10485760　　　　　　　

innodb_log_files_in_group　　　 2　　　　　　　　　　　

innodb_log_group_home_dir　　　 .　　　　　　　　　　

innodb_max_dirty_pages_pct　　　 90　　　　　　　　　　

innodb_max_purge_lag　　　　　　 0　　　　　　　　　　　

innodb_mirrored_log_groups　　　 1　　　　　　　　　　　

innodb_open_files　　　　　　　 300　　　　　　　　　　

innodb_rollback_on_timeout　　　 OFF　　　　　　　　　　

innodb_support_xa　　　　　　　 ON　　　　　　　　　　

innodb_sync_spin_loops　　　　　 20　　　　　　　　　　

innodb_table_locks　　　　　　　 ON　　　　　　　　　　

innodb_thread_concurrency　　　 8　　　　　　　　　　　

innodb_thread_sleep_delay　　　 10000　　　　　　　　　

Content Delivery
Most modern mobile devices will let users store files that are downloaded from WAP or Web sites.
Depending on the delivery method, the device might be notified in advance of the content format (OMA Dowload Separate Delivery) or might “discover” it when starting the download (Direct Download).
Different behaviours might happen across different mobile devices and most notable across different browsers. It is good practice to provide a link to a real file and not a script or servlet that will stream the content. This way you should be able to avoid any problems of file type recognition.

The guidelines described below presume that the browser is able to download the content you are providing. If not, the browser will generally display an error to the user such as “Content not supported”.

How to deliver contents safely
Some content providers will simply want to serve contents to their users and let the users use these contents freely, without any restrictions. In these cases, the best thing to do is to provide links to the real files on the server’s file-system. It is important to set the appropriate MIME type in the server’s configuration files.

If the content provider wants to protect the files delivered there are a few different strategies that can be implemented. First of all, files should be stored in a safe area of the file-system, possibly not accessible from the web server.
Links to the content files can be provided in two ways, the real files or a script that will stream the content to the remote user. There is also a third method, but many developers reported many problems, which is to provide a script or servlet and a set of parameters that will let the script identify the file in the file-system and stream it. For this reason we will not go too much into details about this system.

Whatever delivery system you choose, it is important that the last part of the URI is the name that you want to give to the content. In most cases mobile devices will not allow the user to specify an alternative and the extension is often stored as-is and compared to the MIME type set while storing the file. Specifying a URI that ends with .php and sending a GIF image will often generate an unrecoverable error.

Provide the real file
The safest way to provide files to remote users is to provide the real files. It is important that you set the appropriate MIME types, then simply copy the files from your external directory into a temporary directory accessible by the website. Provide an anchor to it (or the appropriate syntax in the XML file, etc) and deliver the file. Files should be removed after a few days or hours. It is up to you. This is simple to create and manage and only needs the time to develop an automatic cronjob that will remove temporary files when “expired”.

Develop a script
This is a system that will let you protect your files 100%, but might generate some problems if you don’t handle the files correctly. Still works very well in many cases, of course.
Develop a script that according to the minimum parameters is able to recognize the file to be delivered. A couple of examples:

http://mobile.example.com/download/check.php/image.gif
http://mobile.example.com/download/check.php/123456789abcdef/image.gif
The difference is that in the first case you are passing a parameter, image.gif, and the script check.php will identify the file and deliver it. In the second case you are also passing a session id, 123456789abcdef. This can be another step further to log and protect your contents. Store session information in a database and get file and user info from your database. Very useful when you want to generate statistics about how many time a user downloaded a content, which user-agent requested the contents and so on.
Another easy thing to do to protect your content is to store the user-agent string and block any other request with a different user-agent string.

When delivering a content file with a script you will have to manage the HTTP headers. It is required that you set the appropriate MIME type and it is also good practice to specify the file size.

Download methods
You can deliver contents in many ways. The most common is what is generally called a “direct download”. Alternatives are Openwave’s “Downloadfun” and OMA’s “DD”. Sprint‘s GCD should also be mentioned.

Direct Download
Most devices sold in the GSM market starting from 2003-2004 allow users to store remote files locally. Since mobile devices have limited memory and CPU, in most cases users will be allowed to store only files that are in a supported format. Supported formats vary depending on the device, from images to audio and video. PDA‘s and smartphones might allow users to store any file and manually install a third party application, but this is very specific.

If you want to deliver a file simply provide an anchor to the file and the device will let the user store it (if supported!).
Some devices, notably SonyEricsson, might do a request prior to the real download. In general these requests use the HEAD method instead of the GET method. If you are using a script or servlet to serve the file make sure you handle this properly. Some devices might request the file twice. It is rare, but happened (Siemens S55 is an example).

WURFL capability: directdownload_support

DownloadFun
Use the specific URL format.

WURFL capability: downloadfun_support

Read more on the Openwave developer site

OMA Download
OMA Download defines a technology for confirmed download to be used to deliver digital content such as images, sounds, videos and more. The need for this new technology is given because the HTTP protocol itself did not provide the necessary features for content providers to have a check before the download and a confirmation once the download is completed. It happens that devices may not handle the content provided or that content providers need a confirmation once the download is completed. This technology aims at solving these gaps.

WURFL capability: oma_support

Architecture
The architecture is quite simple and straightforward, service providers will produce a Download Description (for this reason this technology is often referred as OMA DD) and the content file. The mobile browser will check if the content is supported (content format, size, etc), download the content, install if needed and, if requested by the service provider, confirm installation. All this is based on standard HTTP communication.

Download Descriptor
The Download Descriptor is a simple XML file that you can create manually or have your application server create it at run-time. The following list describes the required elements of the descriptor:

type - indicates the media type of the object to be executed or rendered. Refer to MIME Media Types
size - it MUST be a positive integer and indicates the size of the content to be downloaded
objectURI - The URI (usually URL) from which the media object can be loaded

The following parameters are optional:

installNotifyURI - The URI (or usually URL) to which a installation status report is to be sent, either in case of a successful completion of the download, or in case of a failure
nextURL - The URL to which the client should navigate in case the end user selects to invoke a browsing action after the download transaction has completed with either a success or a failure
DDVersion - The version of the Download Descriptor technology
name - A user readable name of the Media Object that identifies the object to the user
description - A short textual description of the media object
vendor - The organisation that provides the media object
infoURL - A URL for further describing the media object
iconURI - The URI of an icon
installParam - An installation parameter associated with the downloaded media object
installNotifyURI is the most important parameter and is also the main reason for the definition of the technology. While is left optional for addition in the descriptor is mandatory for the browser implementation. Here is where the notification of the download result will be posted. If you are not going to use this parameter there is probably no need for you to use this technology.
name and description are two very important parameters too. When the user is about to download the content will be presented with a message from the browser showing these parameters. Should be used to aid the user understand what he is downloading. These are optional for the browser implementation too.
nextURL can be very useful, but is optional for the browser implementation. Once the download is completed the user will be automatically redirected to a new page. Some content providers might use it to up-sell more contents, in other cases you might want to redirect to instruction on how to use the downloaded content or other resources.

The file will be downloaded via standard HTTP, this means that you will have to set the appropriate Content Encoding and Content Type. The Content-Type header of the download descriptor should be application/vnd.oma.dd+xml.

Delivery Methods
The DD file and the media object can be delivered all together (A.K.A. Combined Delivery) or separately (A.K.A. Separate Delivery).
The Combined Delivery is probably the fastest for the user as at the request for content, the server replies with a multi-part package that includes both the Download Descriptor and the media object. Once the download is completed, if an installNotifyURI is specified the browser will still confirm the download. The user will not get the notification about the download, there will be no check prior the download and the user will not get a chance to stop the download before it starts if any error such as size too big or format not supported is noticed.
The Separate Delivery is the option that gives the user most options. The browser should present an alert message about the content that is about to download and should do basic checks such as if the media object is supported and there is enough space to store the content. The user is able to confirm the download or block it. Download report will always be notified to the server if installNotifyURI is specified.

Installation status codes
This table is copied and pasted directly from the OMA specifications.

Status Code Status Message Informative description of Status Code usage
900 Success Indicates to the service that the media object was downloaded and installed successfully.
901 Insufficient memory Indicates to the service that the device could not accept the media object as it did not have enough storage space on the device. This event may occur before or after the retrieval of the media object.
902 User Cancelled Indicates that the user does not want to go through with the download operation. The event may occur after the analyses of the Download Descriptor, or instead of the sending of the Installation Notification (i.e. the user cancelled the download while the retrieval/installation of the media object was in process).
903 Loss of Service Indicates that the client device lost network service while retrieving the Media Object.
905 Attribute mismatch Indicates that the media object does not match the attributes defined in the Download Descriptor, and that the device therefore rejects the media object.
906 Invalid descriptor Indicates that the device could not interpret the Download Descriptor. This typically means a syntactic error.
951 Invalid DDVersion Indicates that the device was not compatible with the “major” version of the Download Descriptor, as indicated in the attribute Version (that is a parameter to the attribute Media).
952 Device Aborted Indicates that the device interrupted, or cancelled, the retrieval of the media object despite the fact that the content should have been executable on the device. This is thus a different case from “Insufficient Memory” and “Non-Acceptable content).
953 Non-Acceptable Content Indicates that after the retrieval of the media object, but before sending the installation notification, the Download Agent concluded that the device cannot use the media object.
954 Loader Error Indicates that the URL that was to be used for the retrieval of the Media Object did not provide access to the Media Object. This may represent for example errors of type server down, incorrect URL and service errors.

Sample XML
This example was taken from the OMA Specification document:

image/gif
http:/download.example.com/image.gif
100
http:/download.example.com/image.gif?id=image
Want to know more?
OMA has a specific section called Release Program, look for “Download”. Version 1.0 of the specification provides 3 documents. It is strongly suggested to read the document tagged as “Specification” as it provides all the above information in more detail.
Future version of the specification might provide different documents.

General Content Descriptor (GCD)
A General Content Descriptor (GCD) file is similar to a JAD file. While a JAD describes a J2ME MIDlet for download, a GCD describes downloads like ringtones and pictures. GCD’s are plain text files and you can create them using any simple text editor like Windows Notepad. If you’d like your phone to download your own picture, then you’ll need a GCD file.
http://sprintdeveloper.com/article16.html
http://web.ics.purdue.edu/~butta/vision.html
GCD Creator

Here are some C# Sample files.

GCD Install-Notify

Nokia COD
COD stands for Content Object Descriptor and is a proprietary technology of Nokia. It was developed around 2002 and only a few devices ever supported it. The technology was developed an implemented while waiting for the formal implementation of OMA DRM and OMA DD.
COD takes inspiration from Sun’s MIDP OTA delivery system, which means a file descriptor and the content itself. Download happens in two steps, the site should provide a link to a COD file which contains all the needed information to download the content file. The device will present the user with a short description of the content and content type. The user confirms and the download starts. The COD has a set of required parameters and optional parameters.
COD offers at least 2 advantages, first of all the user is presented with a nice menu with a short description of the content and may choose to download or not. This is certainly a nice feature for the end-users, but it will not change your life, of course. The BIG advantage of COD over Direct Download is that developers can specify a URL to be notified when the download is completed successfully, much like the Install-Notify URL of MIDP. It is not a case that the parameter name is COD-Install-Notify. This can be a life-saver!

COD was an in-between technology and when OMA DRM and OMA DD where formalized, Nokia abandoned the technology.

Useful links, if they don’t die:

OTA download for generic content - Service Developer's Guide
Nokia DRM AND DOWNLOAD FREQUENTLY ASKED QUESTIONS, 3.5 What is the relationship between OMA Download and COD?

引用
http://www.thewirelessfaq.com/

方素正窩

2009年4月17日星期五

聲音影像處理軟體使用記錄

MySQL InnoDB存儲引擎的一些參數

2009年4月5日星期日

書籤binary簡訊的筆記

2009年4月2日星期四

手機的OTA下載

追蹤者

2009年4月17日 星期五