QNX操作系统下的QDB数据库开发指南

需积分: 7 36 浏览量更新于2024-07-16 收藏 1.06MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"QNX_Database_Developers_Guide.pdf 是一份关于在QNX嵌入式操作系统上进行数据库开发的指南。文档详细介绍了QNX Software Development Platform 6.6版本中的QDB（QNX Database）的使用和开发，由QNX Software Systems Limited，即BlackBerry Limited的子公司编写并发行。该指南涵盖了从开始使用QDB到命令行操作，数据库配置，存储和维护等多个方面。" QNX是一个实时操作系统，广泛应用于嵌入式系统，特别是对性能、安全性和可靠性的要求极高的场合。QDB是QNX系统中内建的数据库系统，专为嵌入式环境设计，具有高效、轻量级和实时性等特点。在《QNX Database Developers Guide》中，首先介绍了如何开始使用QDB，包括启动QDB服务器，加载和卸载数据库。这通常涉及系统服务管理，如通过命令行或配置文件来控制QDB服务器的启动和停止。接着，文档详细讲解了PPS（Process and Program Services）配置路径，这是在QNX系统中管理服务和程序的关键部分。PPS配置路径有助于开发者理解如何配置QDB服务以适应不同的系统需求。数据库配置对象是QDB的重要组成部分，它们定义了数据库的属性和行为。这部分内容可能包括数据存储模式、并发控制、事务处理等设置。开发者需要了解这些对象以便正确配置数据库以满足特定应用的需求。在数据库存储章节，指南会阐述QDB如何管理数据的物理存储，包括内存映射文件和磁盘空间的使用。此外，可能还会涉及到如何优化存储效率，确保数据的快速访问和高效利用。 Schema文件是定义数据库结构的文件，包括表、列、索引等元素的描述。理解如何创建和管理schema文件对于数据库的设计和迁移至关重要。文档还提供了数据库文件的总结，列出各种类型的数据文件及其作用，这对于理解和调试数据库系统非常有用。第二章主要关注QDB的命令行工具，这是管理员和开发者进行数据库管理和操作的主要界面。这里可能包含了如何执行临时存储管理，测试数据库完整性，以及共享连接等高级功能的说明。命令行工具的熟练使用能极大地提高工作效率。临时存储文件系统是QDB处理临时数据的地方，它有助于在有限的内存资源下优化数据库性能。数据库完整性测试则确保数据的一致性和准确性，这对于任何数据库系统来说都是关键。最后，共享连接部分可能涉及到如何允许多个用户或进程同时访问数据库，以及如何处理并发控制和锁机制，这对于多用户环境下的QDB使用尤其重要。总体而言，《QNX Database Developers Guide》为开发者和系统管理员提供了全面的QDB使用和开发指南，帮助他们有效地在QNX嵌入式环境中构建和管理数据库系统。这份文档是深入理解和掌握QNX系统数据库功能的宝贵资源。

资源详情

资源推荐

You can then override the PPS configuration path by running the qdb utility with the

-c option, as follows:

qdb -c /temp/qdb

The directory named in the PPS configuration path must exist before you start QDB.

You can launch multiple instances of QDB with different configuration paths so long

as each path is based on the PPS mountpoint. So in the above example, you could

also run an instance of QDB with the PPS configuration path /temp/customerdbs.

We recommend you use separate QDB device mountpoints for separate QDB instances;

this is done with the -n option on the qdb command line. For details, see the QDB

Command Line (p. 27) chapter.

Getting Started with QDB

Database configuration objects

QDB databases are managed with configuration objects, each of which configures one

database. The configuration objects are text files that specify the paths to the database

schema and storage files as well as policy settings such as backups.

The files are named after the databases that they configure. For example, suppose

you have two media content databases named hdd and cdrom. You would then create

two configuration objects named hdd and cdrom. For an overview of all

database-related files, see “Summary of database files (p. 25)”.

By using a separate SQLite storage file for each database, QDB allows you to

dynamically load and unload individual databases so you can keep in memory only

the data needed for the active client application.

QDB doesn't support “on-the-fly” configuration changes after a database is

loaded. To modify the configuration, you must unload the database, update

its configuration object, and reload the database. You must also ensure that

the changes are compatible with the previous configuration.

Configuration object contents

The database configuration object gets parsed by QDB to set up the database. Lines

specifying parameters are in the form key::value. Unknown parameter types are

ignored and so they can be made into comments, but you must still use the :: delimiter

on the comment line. For example, you can enter MyComment:: on a line and QDB

will treat it as an unsupported parameter and ignore that line when parsing the file.

For an example of a database configuration, see “Sample configuration object (p.

21)”.

The configuration object must contain this parameter:

Filename

The name of the database storage file, which is the raw SQLite file. It must

have an absolute path but it can refer to any file location. At database loading

time, either this file or the directory in which it will be created must exist;

otherwise, the loading attempt fails and QDB sets the status to Error. If the

database file doesn't exist but its parent directory does, the file is restored

from the newest valid backup (if possible) or a blank database file is created.

All other database configuration parameters are optional. You can define these

parameters:

Database configuration objects

BackupDir

A comma-separated list of directories that store database backups. When

you specify multiple directories, they're used in rotation to store the backup

files. This feature ensures that should a backup be interrupted or aborted

by a power failure, another older backup is still available.

These directories must exist at loading time (though they don't need to

contain valid backups); otherwise, the loading attempt fails and QDB sets

the database status to Error. If any existing backup files are located in these

directories, they are sorted by date and overwritten oldest-to-newest when

performing backup operations and used in newest-to-oldest order when

restoring a missing or corrupt database.

BackupVia

An interim directory that the database is copied into as part of the backup.

To make sure the backup is consistent, QDB places a read lock on the

database while copying and compressing it, so the database may be locked

a long time if the destination is slow (e.g., flash).

Suppose you specify:

BackupVia::/dev/shmem

When backing up, QDB locks the database, copies it to /dev/shmem, and

releases the lock. Then, in a second step, QDB copies and compresses the

database into the location specified by BackupDir, without needing to lock

the database.

ClientSchemaFile

The name of the file (with an absolute path) that contains the SQL commands

to execute every time a client calls qdb_connect() (p. 131).

Use this feature for changing database settings that can't be premanently

modified. An example would be the PRAGMA commands, which modify

non-table data such as journaling mode or case-sensitive-like status. Don't

use client schema files to do regular database work because doing so will

slow down new connections.

You can also use this mechanism to implement cross-database triggers.

Collation, Function

These entries install user-provided collation (sorting) routines and

scalar/aggregate functions. The argument format is a comma-separated list

of library symbols in the form tag@library.so, where tag is the symbol name

Database configuration objects

of the function description structure and library.so is the name of the shared

library containing the code.

Unlike the paths to other key files, the library file paths can be relative or

absolute. Relative paths are looked up in the library search directories (refer

to dlopen() in the QNX Neutrino C Library Reference for more detail). In this

release, you can install only one collation function but many scalar functions

per database. For the latter type of functions, you can specify symbols from

as many shared libraries as you want. For example, you could write:

Collation::UTF-8_Sort@libsort.so

Function::sampleData@libstats.so,implToMtrc@libunits.so

For information about the function description structures and the setup and

sorting functions that you must define, see the Writing User-Defined

Functions (p. 95) chapter.

QDB checks for the existence of the libraries and the specified symbols at

loading time. If any are not found, the loading attempt fails and QDB sets

the database status to Error.

Compression

The compression algorithm to apply to backups. The supported options are:

• none (for no compression, which is the default)

• lzo (for LZO compression)

• bzip (for BZIP2 compression)

• diocopy (for direct I/O copy)

The lzo compression algorithm is the fastest but the bzip algorithm offers

the highest compression. Direct I/O doesn't perform any compression; instead,

QDB uses the fileset (p. 235) utility to copy the database using direct

memory access (DMA). Direct I/O is a fast way to back up data if the

persistent storage supports DMA.

The compressed files are named by adding the appropriate extensions to

the original database filenames. By default, backup files aren't compressed.

CompressionVia

This entry is used with the BackupVia entry and any Compression setting

specified for the backup. By default, the BackupVia feature first makes a

raw/uncompressed copy of the database in the temporary directory and then

performs the compression. This works if you have enough space and it

read-locks the database for the least amount of time, but you can use less

space (at the expense of more time) by compressing during the copy. This

Getting Started with QDB

剩余243页未读，继续阅读

namezbp

粉丝: 4
资源: 21

QNX操作系统下的QDB数据库开发指南

OpenWF_Display_Configuration_Developers_Guide.pdf

QNX_Adaptive_Partitioning_User_Guide_.pdf

cmake -DCMAKE_TOOLCHAIN_FILE=../qnx_aarch64_toolchain.cmake ..

Main.Func_CanDataProcess.ReadCanData(UniversalData.CanBus1, QNX_canvar.R_205_0, false , this, "setYuanKongJingKong");

Android编译显示QNX_HOST environment variable not set.

The QNX_HOST/QNX_TARGET environment variables must be set

qnx_hyp_rx_dispatch

QNX_TARGET

qnx_crypt和crypt的区别

基于大模型技术的算力产业监测服务平台设计

This_honeypot_supports_Telnet_and_SSH_two_protocol_FF-Pot.zip

吉他谱_What I've Done - Linkin Park.pdf

吉他谱_Too sweet - Hozier.pdf

Linux使用的一些笔记，包括shell命令，软件，一些实用的网站的整理_Linux_note.zip

基于ssm的机房预约系统设计与实现.docx

最新资源