As part of the backup and recovery plan, along with periodically testing the recovery process, it is considered a best practice to validate the backup database after a successful backup.  This is the best way to ensure that your production database is valid, and that the backup is clean and will actually be recoverable should you need it.

Unfortunately, starting a backup database on a server would cause (at a minimum) a checkpoint to occur, advancing the expected starting offset for the log file associated with the backup database.  This meant that should you ever have to use that backup database for recovery, you would not be able to apply any log files from your production database to it because expected log offsets would no longer match.

In order to ensure that the backup is valid, and that it can still be used for recovery, you have to start the backup database in “read-only” mode (using the server –r option or the FOR READ ONLY clause of the START DATABASE statement) to ensure no changes are made to the database/log.  This works well in most, but not all cases.  If your backup was started and there were open transactions in the database (which is common), the backup database has to go through recovery when it starts (to either complete or rollback those transactions and ensure an ACID compliant database), which means you cannot use read-only mode for validation.

In these cases, you have to make a copy of the backup database, start it up and let the database recover, and then do the validation.  Obviously this adds a lot of overhead to the backup plan, in both time and disk space.

For version 17, we have addressed this by adding a new in-memory mode called "in-memory validation" or IMV, which is intended to allow backups to be validated without making a separate copy of the database and log files. Unlike the other in-memory modes for SQL Anywhere (in-memory checkpoint-only mode (-im c) and in-memory never-write mode (-im nw )), which are separately licensed, In-memory validation mode is included with all versions of SQL Anywhere: it is not a separately licensed component.

In-memory validation mode is enabled by specifying the "-im validation" switch (or "-im v" for short) on the server command line:

dbsrv17.exe –im v foo.db

The server in-memory validation mode has the following behaviours:

• Database files and log files are never modified on disk
• All modifications are maintained in the database server's cache and therefore the server may run out of cache (ie. memory) if the checkpoint log, redo log and/or undo logs modify a large enough number of database pages.
• The server will create & use a temp file to alleviate cache pressure where it can.
• In-memory modifications (DML, DDL, etc) can only be made by the recovery tasks (ie. for applying the checkpoint log, redo log(s) and undo log(s)).
• All non-recovery operations such as those from client connections, user-defined events, etc are read-only (similar to the server read only (-r) mode).
• Databases will not be shut down after recovery when a flag such as -a, -ad, or -f is specified.
• The server will ignore the "-r" (read-only) command line option(s) and ignore the FOR READ ONLY clause on START DATABASE statements.
• A backup of a database running on a server in IMV mode will generate a backup identical to the original, unmodified database file that was started on the IMV server.

Updates to DBValid/DBValidate()

In addition to the behaviour changes in the server, the dbvalid command line tool now supports a new "-im <mode>" switch to allow control over the in-memory mode of the server but only for servers that are autostarted.  Valid modes include: none, v, c, nw. The default mode is v.

When a mode other than 'none' is used (including the default 'v' mode), dbvalid appends the "-im <mode>" switch the StartLine connection parameter, if provided. Otherwise, StartLine is set to "dbeng16 -im <mode>".  If StartLine already contains a "-im <mode>" command line switch, the server will respect the first one (ie, the one from the connection string, not the one appended by dbvalid). When –im 'none' is specified, StartLine is neither set nor modified.

The dbtools library DBValidate(…) method has also been updated to support the new in memory mode option.

Historically, the number of connections that an individual user may make to a server is limited by the server license.  For a chip license, the limit is set by default to 32766, but can be changed using the server -gm option.  You can use the server property() function to get the MaxConnections property, which will return the maximum number of connections allowed to the server.  SQL Anywhere 17 now supports limiting the total number of connections to an individual database by setting the public database option “max_connections”.  This will cause SQL Anywhere to limit the total database connections to the specified number.  The max_connections option can be set as a temporary option to allow the limit to be set without persisting it in the database.

Note that the database option cannot be used to override the server setting for the maximum number of connections. Therefore, if the max_connections database option is set to a number larger than the server property setting for ‘MaxConnections’, then it has no effect.  The total number of connections that will be allowed to a database is determined by the following rules:

• The total number of server connections (SELECT property('MaxConnections') FROM DUMMY) cannot be exceeded (except by 1 user with DROP ANY CONNECTION privilege)
  • The error SQLERR_TOO_MANY_CONNECTIONS will be returned
• The total number of database connections (SELECT db_property('MaxConnections') FROM DUMMY) cannot be exceeded (except by 1 user with DROP ANY CONNECTION privilege)
  • The error SQLERR_TOO_MANY_DB_CONNECTIONS will be returned
• The total number of user connections limit cannot be exceeded

There is also a new database-level property ‘MaxConnections’ that reflects the maximum number of connections that can be made to the database, as defined above.

Only “licensed” connections count toward the database connection limit.  Internal connections for events, mirroring, monitoring, etc... are not counted. HTTP connections are, however, included.

For example, with a personal server (or one whose license limits it to 10 connections):

If we set max_connections to 20:

Because the maximum number of connections to the personal server is 10, increasing the max_connections option beyond this has no effect.

However, if we set the max_connections value to 5, we see the following:

The current database is limited to 5 connections.  The rest of the connections (5) are available to other databases running on the server.

Note: There is a provision built into the server that allows for a single user that has the DROP ANY CONNECTION privilege to connect to the database even when the connection limit has been reached.  This allows an administrator to connect and remove one or more connections if required (eg. if all other connections are deadlocked, if a connection is overusing resources, etc…)

Existing databases (version 16 and older) will not make use of this feature.  If the max_connections database option is set in these databases, it will be ignored and these databases will continue to work as they did previously. In addition, if you try to upgrade a database using ALTER DATABASE UPGRADE and the max_connections option has been set, the upgrade will fail with the error SQLERR_UPGRADE_CONFLICTING_OPTION.  The max_connections option would have to be removed before the upgrade would be able to continue.

Hello,

I have some trouble concerning the following mini-example ( see attached txt-file ). I'm trying to establish a connection from my mobile device ( Windows Mobile 6.5 ) to a SQL server. The connectionstring works fine on my Notebook.

My mobile device returns a SAException "Database server not found"

Is there anything I should know about the connectionstring with regard to the mobile device OS?

Thanks for any help!

Best Regards

Timo

锁类型

为了确保数据库一致性并支持事务之间适当的隔离级别，数据库服务器使用多种类型的锁。

模式锁模式锁用于序列化对数据库模式的更改，并确保使用表的事务不受由其它连接发起的模式更改的影响。例如，通过插入新列更改表结构的事务可锁定一个表，这样其它事务就不会受到模式更改的影响。在这种情况下，必须限制其它事务进行访问，以防止出现错误。

行锁行锁通过允许多用户访问和修改行级别的特定表来确保并发事务之间的一致性。例如，事务可锁定特定的行以防止另一个事务对其进行更改。行锁类有：读（共享）锁定、写（独占）锁定以及意图锁。

表锁表锁锁定表中的所有行，并在事务更新表时阻止其它事务更新表。表锁类型有：读（共享）锁定、写（独占）锁定以及意图锁。

位置锁位置锁确保表的顺序扫描或索引扫描内的一致性。事务通常按顺序或使用由索引确定的顺序对行进行扫描。在这两种情况下，都可以将锁放置在扫描位置上。例如，在索引中放置锁可以防止其它事务在索引中插入具有特定值或特定值范围的行。

锁持续时间事务通常会保存锁，直到完成该事务。此行为可防止其它事务进行修改，以免无法回退原始事务。在隔离级别 3，必须在事务结束之前保存所有锁，以确保事务的可序列化性。当行锁用于实现游标稳定性时，它们不用在事务结束前保存。只要对象行是当前的游标行，就保存这些行锁。在大多数情况下，这段时间要比事务的生存期短。使用 WITH HOLD 打开游标时，可以在连接的生存期内一直保存锁。锁可保持以下时长：

位置短期锁定，如特定行上用于在隔离级别 1 实现游标稳定性的读锁定。

事务例如，一直保持到事务结束的行锁、表锁和位置锁。

连接一直保持到事务结束之后的模式锁，如使用 WITH HOLD 游标时创建的模式锁。

模式锁

模式锁用于序列化对数据库模式的更改，并确保使用表的事务不受由其它连接发起的模式更改的影响。

例如，共享模式锁可防止 ALTER TABLE 语句在表正被另一连接上打开的游标读取时从该表删除列。

有两类模式锁：共享模式锁和独占模式锁。

共享锁

当事务直接或间接引用数据库中的表时，会获取共享模式锁。共享模式锁不会互相冲突；任意数量的事务都可以同时在同一表上获取共享模式锁。共享模式锁会一直保持到通过 COMMIT 或 ROLLBACK 完成事务为止。

允许持有共享模式锁的任何连接更改表数据，只要更改不与其它连接冲突。以共享（读取）模式锁定表模式。

独占锁

通常使用 DDL 语句修改表的模式时，会获取独占模式锁。ALTER TABLE 语句便是 DDL 语句的一个示例，该语句在对表进行修改之前获取该表的独占模式锁。任何时候只有一个连接可获取表的独占模式锁。锁定该表模式（共享或独占）的所有其它尝试都将阻塞，或失败并产生错误。以隔离级别 0（最低限制的隔离级别）执行的连接将不能从以独占模式锁定的表中读取行。

只有持有独占表模式锁的连接才能够更改表数据。将表模式锁定为供单个连接独占使用。

行锁

行锁可防止更新丢失以及其它类型的事务不一致。

行锁可确保在某个事务完成（通过发出隐式或显式 COMMIT 语句提交更改，或通过 ROLLBACK 语句中止更改）前，由该事务修改的任何行无法被其它事务修改。

有三类行锁：读（共享）锁定、写（独占）锁定以及意图锁。数据库服务器会为每个事务自动获取这些锁。

读锁定

当事务读取某行时，事务的隔离级别会确定是否获取读锁定。在某一行被放置了读锁定后，任何其它事务都不能在该行上获取写锁定。获取读锁定可确保另一个事务不会修改或删除正在被读取的行。任意数量的事务可以同时在任意一行上获取读锁定，因此读锁定有时也称为共享锁，或非独占锁。

读锁定可保持不同的时间。在隔离级别 2 和 3 上，事务获取的任何读锁定会一直保持到事务通过 COMMIT 或 ROLLBACK 完成为止。这些读锁定称为长期读锁定。

对于以隔离级别 1 执行的事务，数据库服务器在游标所在的行上获取短期读锁定。随着应用程序滚动游标，会释放前面行上的短期读锁定，并在后面的行上获取新的短期读锁定。此技术称作游标稳定性。因为应用程序在当前行上保持读锁定，所以在应用程序离开该行之前，其它事务无法对该行进行更改。如果游标是通过涉及多个表的查询打开的，则可获取多个锁。仅当必须在请求（通常，这些请求是应用程序发出的 FETCH 语句）间保持游标位置时，才获取短期读锁定。例如，处理 SELECT COUNT(*) 查询时不会获取短期读锁定，因为通过此语句打开的游标将永远不会位于特定的基表行上。这种情况下，数据库服务器仅需要保证读取已提交的语义，即该语句处理的行已被其它事务提交。

以隔离级别 0（读取未提交数据）执行的事务不会获取长期读锁定或短期读锁定，因此也不会与其它事务冲突（除了独占模式锁）。但是，隔离级别 0 事务可能处理其它并发事务所做的未提交的更改。可以使用快照隔离避免处理未提交的更改。

写锁定

事务在插入、更新或删除行时将获取写锁定。此行为适用于处于所有隔离级别（包括隔离级别 0 和快照隔离级别）的事务。获取了写锁定后，任何其它事务都不能在相同行上获取读锁定、意图锁或写锁定。写锁定也称为独占锁，因为任何时候只能有一个事务可以在某一行上持有独占锁。只要一个事务在一行上持有某种类型的锁定，任何其它事务就不能在同一行上获取写锁定。同样，一个事务获取了写锁定后，其它事务要求锁定该行的请求都将被拒绝。

意图锁

意图锁（也称为意图更新锁）表示修改特定行的意图。事务进行以下操作时，会获取意图锁：

发出 FETCH FOR UPDATE 语句

发出 SELECT...FOR UPDATE BY LOCK 语句

将 SQL_CONCUR_LOCK 用作 ODBC 应用程序中的并发基础（使用 SQLSetStmtAttr ODBC API 调用的 SQL_ATTR_CONCURRENCY 参数设置）

发出 SELECT...FROM T WITH (UPDLOCK) 语句

意图锁不会与读锁定冲突，因此获取意图锁不会阻塞其它事务读取同一行。但是，意图锁确实会防止其它事务在同一行上获取意图锁或写锁定，这样就保证了在更新前该行无法被任何其它事务所更改。

如果正在使用快照隔离的事务请求意图锁，则仅当该行在数据库中未修改且为所有并发事务公用时，才会获取意图锁。但是，如果该行是快照副本，则不会获取意图锁，因为原始行已被其它事务所修改。快照事务要更新该行的任何尝试都将失败，并会返回快照更新冲突错误。

表锁

表锁可在事务更新表时阻止其它事务更新表。

有三类表锁：共享表锁、意图写表锁和独占表锁。事务结束（发生 COMMIT 或 ROLLBACK）后释放表锁。

表锁不同于模式锁：表锁在表的所有行上放置锁，而模式锁在表的模式上放置锁。

下表显示了哪两个表锁之间会发生冲突：

共享表锁

共享表锁允许多个事务读取基表的数据。拥有基表的共享表锁的事务可以修改此表，前提是其它事务均未持有对所修改行的任意类型的锁。

例如，通过执行 LOCK TABLE...IN SHARED MODE 语句可获取共享表锁。REFRESH MATERIALIZED VIEW 和 REFRESH TEXT INDEX 语句还支持 WITH SHARE MODE 子句，使用该子句可以在刷新操作发生的同时在基础表上创建共享表锁。

意图写表锁

意图写表锁（也称作意图表锁）会在事务第一次获取行上的写锁定时隐式获取。即在更新、插入或删除行时获取意图表锁。与共享表锁一样，意图表锁会一直保持到通过 COMMIT 或 ROLLBACK 完成事务为止。意图表锁与共享表锁和独占表锁冲突，但不与其它意图表锁冲突。

独占表锁

独占表锁可阻止其它事务修改表的模式或数据，包括插入新数据。与独占模式锁不同，以隔离级别 0 执行的事务仍可读取具有独占表锁的表中的行。一次只能有一个事务在任意表上持有独占锁。独占表锁与所有其它表和行锁冲突。

使用 LOAD TABLE 语句时会隐式获取独占表锁。

可通过使用 LOCK TABLE...IN EXCLUSIVE MODE 语句获取独占表锁。REFRESH MATERIALIZED VIEW 和 REFRESH TEXT INDEX 语句还提供了 WITH EXCLUSIVE MODE 子句，使用该子句可以在刷新操作发生的同时在基础表上放置独占表锁。

位置锁

位置锁是一种键范围锁定方式，旨在防止由于幻像或幻像行的存在而导致的异常。

仅当数据库服务器处理以隔离级别 3 运行的事务时，才涉及到位置锁。

以隔离级别 3 运行的事务是可序列化的。隔离级别 3 的事务的行为不应受其它事务的并发更新活动影响。特别是，在隔离级别 3 上，事务不能受引入可影响计算结果的行的 INSERT 或 UPDATE（幻像）所影响。数据库服务器使用位置锁防止此类更新发生。正是通过此附加锁定来区分隔离级别 2（可重复读取）和隔离级别 3。

为了防止创建幻像行，数据库服务器在表的物理扫描中获取位置锁。对于顺序扫描，扫描位置基于当前行的行标识符。对于索引扫描，扫描的位置基于当前行的索引键值（该值可以是唯一的也可以是不唯一的）。通过锁定扫描位置，一个事务可以防止其它事务按照行的顺序执行与特定值范围相关的插入。此行为适用于可更改索引属性值的 INSERT 语句和 UPDATE 语句。扫描位置锁定后，UPDATE 语句可视为请求对索引条目执行 DELETE，随后紧跟一个 INSERT 请求。

支持两类位置锁：幻象锁与插入锁。这两类锁都是共享锁，因为任意数量的事务可以在同一行上获取相同类型的锁。但是，幻像锁和防幻像锁互相冲突。

幻像锁

幻像锁（有时也称为防插入锁）放置在扫描位置上以防止其它事务随后创建幻像行。获取了幻像锁后，它可以防止其它事务在表中被放置了防插入锁的行与前一行之间插入新行。幻像锁是长期锁，它会一直保持到事务结束。

只有以隔离级别 3 运行的事务才能获取幻像锁；只有该隔离级别可保证幻像的一致性。

对于索引扫描，通过索引读取的每行上都会获取幻像锁，且会在索引扫描的末尾获取一个额外的幻像锁，以防止在满足条件的索引范围的末尾处向索引插入行。索引扫描上的幻像锁可防止向表中插入新行时创建幻像，也可防止会导致在幻像锁所在位置创建索引条目的索引值的更新。

对于顺序扫描，表中的每行上都会获取幻像锁，以防止任何插入操作变更结果集。隔离级别 3 扫描通常会对数据库并发产生负面影响。虽然一个或多个幻像锁会与插入锁冲突，而一个或多个读锁定会与写锁定冲突，但是幻像锁/插入锁和读锁定/写锁定之间不存在交互。例如，虽然不能在包含读锁定的行上获取写锁定，但可以在只具有幻像锁的行上获取写锁定。这种灵活的安排为数据库服务器提供了更多选择，但这也意味着数据库服务器必须经常注意在获取幻像锁的同时也应获取读锁定。否则，其它事务可以删除该行。

插入锁

插入锁（有时也称作防幻像锁）是短期锁，放置在扫描位置上以保留插入行的权利。插入锁仅在插入期间保持；该行正确插入数据库页后，会立即在该行上放置写锁定以确保一致性，然后释放插入锁。一个事务在某一行上获取了插入锁后，其它事务都不能在同一行上获取幻像锁。插入锁是必需的，因为数据库服务器必须预料任何活动连接上的隔离级别 3 扫描操作，而任何新的请求都可能引发隔离级别 3 扫描。当幻像锁和插入锁由同一事务持有时，它们之间不会互相冲突。

使用 Profiler 来快速查看您的数据库中当前运行的 SQL 语句，比较过程的运行时间并分析这些对象在您的数据库中是如何进行交互的。

使用 Profiler 来标识如下问题：

• 死锁和连接阻塞。
• 长期运行并且开销庞大的查询以及重复运行的查询。
• 高开销的隐藏过程，例如，触发器、事件和嵌套的存储过程调用。
• 过程主体中的潜在问题区域。

解决问题时请考虑以下步骤：

1. 1. 启动 Profiler，并使用数据库的用户凭据来连接至出现问题的数据库。此用户必须具有 SYS_RUN_PROFILER_ROLE 系统角色才能使用 Profiler。
2. 2. 运行应用程序。

当 SQL 语句在数据库中运行时，在 Profiler 的“操作”选项卡中将显示其相应的分析信息。

因为 Profiler 实时显示分析信息，您可以对数据库进行变更并查看其立即产生的效果。

1. 3. 保存结果并断开 Profiler 连接。
2. 4. 查看结果。

在解决数据库性能较差的问题时，通常情况下首要任务是确定主要原因是应用程序还是数据库服务器。要确定客户端应用程序所消耗的处理时间，可使用 Profiler 中的“操作”选项卡并按单个连接过滤结果。如果来自该连接的不同请求之间存在时间差异，则主要的延迟发生在客户端应用程序内。

参考 Profiler 顶部的“服务器负载”图形来查看有关数据库服务器的 CPU 使用率以及磁盘和网络使用率的数据。当预计数据库服务器会因为执行备份、检查点或其它内部服务器活动而降低性能时，该图也会对时间进行突出显示。

1. 5.    当您需要收集更多数据或验证建议更改时，请根据需要重新连接至 Profiler 并重复上述步骤。

在此节中：

分析数据库 (Profiler)

启动数据库分析来确定如下问题：死锁和连接阻塞、长时间运行并且开销庞大的查询和性能降低的时间段。

分析过程、函数、事件和触发器 (Profiler)

分析您的存储的 SQL 对象（如过程、函数、事件和触发器）来标识可影响系统性能的对象或语句。确定可能的解决方案后，对其进行测试，然后比较您的结果。

过滤器语法 (Profiler)

使用 [过滤器] 框来过滤 Profiler 中显示的信息，只留下您感兴趣操作的信息。

分析数据库 (Profiler)

启动数据库分析来确定如下问题：死锁和连接阻塞、长时间运行并且开销庞大的查询和性能降低的时间段。

先决条件

您必须具有 SYS_RUN_PROFILER_ROLE 系统角色才能使用Profiler。

上下文

Profiler是一种开发工具，用于实时记录数据库中的活动，并以简单易用的格式显示这些活动。

过程

1. 1. 在 Interactive SQL 中，连接到要分析的数据库。

例如，在“连接”窗口中选择“使用连接字符串进行连接”操作并指定以下启动参数：

UID=DBA;PWD=sql;"DSN=SQL Anywhere 17 Demo"

1. 2. 启动Profiler并连接到数据库。
2. a. 在 Interactive SQL 中，单击“工具”“SQL Anywhere Profiler”。
3. b. 当出现提示时，请接受缺省分析选项并单击“确定”。

在Profiler的“操作”选项卡中显示当前运行的 SQL 语句的相关信息。

1. 3. 运行应用程序。
2. 4. 保存分析数据。单击“文件”“另存为”。
3. 5. 单击“文件”“断开连接”  来结束数据库分析。
4. 6. 查看分析信息。使用右上角的“过滤器”框来查找您感兴趣的信息。

分析过程、函数、事件和触发器 (Profiler)

分析您的存储的 SQL 对象（如过程、函数、事件和触发器）来标识可影响系统性能的对象或语句。确定可能的解决方案后，对其进行测试，然后比较您的结果。

先决条件

您必须具有 SYS_RUN_PROFILER_ROLE 系统角色以使用Profiler。

上下文

过程分析可提供过程、用户定义的函数、事件、系统触发器和触发器的执行时间测量值。将当前结果保存为基线，然后对过程进行增量更改。在每次更改后运行该过程，然后将新的结果与基线进行比较，以查明更改效果是否符合预期。

过程

1. 1. 在 Interactive SQL 中，连接到要分析的数据库。

例如，在“连接”窗口中选择“使用连接字符串进行连接”操作并指定以下启动参数：

UID=DBA;PWD=sql;"DSN=SQL Anywhere 17 Demo"

1. 2. 启动Profiler并连接到数据库。
2. a. 在 Interactive SQL 中，单击“工具”“SQL Anywhere Profiler”。
3. b. 当出现提示时，请接受缺省分析选项并单击“确定”。

在Profiler的“操作”选项卡中显示数据库中当前运行的 SQL 语句的相关信息。

1. 3. 在您的应用程序中，执行您想要分析的存储的 SQL 对象。
2. 4. 单击Profiler中的“分析”选项卡。

顶部窗格中列出了自您开始分析后已执行的过程、触发器、函数和事件。该列表中显示了已经执行的存储的 SQL 对象。

1. 5. 在顶部窗格中，单击您的存储的 SQL 对象。

特定于该对象的详细信息将出现在底部窗格中。

1. 6. 查看底部窗格中的内容，其中包括代码中各个行的结果。通常情况下，对于代码中与其它行相比执行时间较长的行，应对其进行分析，并考虑是否能通过更有效的方法来获得相同的功能。
2. 7. 单击“基线”来创建当前结果的基线。
3. 8. 对代码进行更改并在您的应用程序中重新运行存储的 SQL 对象。

因为Profiler实时显示分析信息，您可以对数据库进行更改并查看立即产生的效果。

1. 9. 观察Profiler中的性能变化。
2. 10.  重复上述步骤，直到您对变化满意为止。
3. 11.  单击“文件”“断开连接”  来结束数据库分析。

过滤器语法 (Profiler)

使用 [过滤器] 框来过滤Profiler中显示的信息，只留下您感兴趣操作的信息。

语法filter_expression{ [ " ] string [ " ] | [ attribute-value-pair ] } ...

attribute-and-value:

user=user-name[,...]

connection=connection-id[,...]

connectionName=connection-name[,...]

connectionName containsstring[,...]

state={blocked | failed | running }

severity={debug | information | warning | error | critical | always}

severity{= | < | > | <>} severity-number

type=operation-type[,...] 

date={today | yesterday | this week | last week | day-of-week | date-range}

executionTime{=|<|>}number { hours | minutes | seconds | h | m | s | ms }

blockedTime{=|<|>}number { hours | minutes | seconds | h | m | s | ms }

betweendate-formatanddate-format

AppInfo.appinfo-key=string

AppInfo.appinfo-keycontainsstring

severity-number:

An integer between 0 and 255

date-range:

fromdate-formattodate-format

date-format:

YYYY-MM-DD[ time-format ]

time-format:

HH [:MM[:SS] [ am | pm ] ]

day-of-the-week:

{ Monday|Tuesday|Wednesday|Friday|Saturday|Sunday }

operation-type:

{connect

|consoleMessage

|disconnect

|dropPreparedStatement

|executePreparedStatement

|executeStatement

|internal

|prepareStatement

|webServerMessage

|user-defined-trace-event-name }

appinfo-key:

{ API | EXE | HOST | IP | OS | OSUSER | PID | THREAD | TIMEZONEADJUSTMENT | VERSION }

参数

以下列表包含有关某些参数的其它信息。

• Date和between子句

任何指定的日期指的是语句开始执行的时间。

between子句包括两个指定时间之间任意时间点运行的语句。指定日期必须具有相同的格式。

• AppInfo子句

AppInfo子句根据客户端应用程序的属性（如客户端计算机的 IP 地址、运行此客户端进程的操作系统等）对语句进行过滤。你可以为appinfo-key指定与 AppInfo 连接属性的key值相同的值。例如，指定AppInfo.execontainsdbisql以查看 Interactive SQL 中执行的语句。

• Severity子句

本子句指的是警告或错误消息的严重程度。例如，以下内容为 CREATE TEMPORARY TRACE EVENT 语句的事件严重程度：0=经常、1-50=严重、51-100=错误、101-150=警告、151-200=信息、201-254=调试。

注释

缺省情况下，Profiler会显示所有从其分析的数据库中收集的分析信息。当排除一个特定的问题时，将信息量减少至只显示与你的问题相关的信息，将十分有用。例如，过滤出与特定用户或连接不相关的所有事件。

单击右上角的 [过滤器] 框，然后单击下拉菜单中的 [添加过滤器表达式] 来通过选择不同的过滤器条件创建过滤器表达式。也可使用过滤器语法来创建复杂的过滤器表达式。

将文本用引号引起来使其被视为文字文本。如果引用文本中包含引号，则使用反斜线对其进行转义。如果引用文本中包含反斜线，则除非反斜线后有引号，否则不需要对其进行转义。

过滤器语法中的所有子句并非都适用于所有事件操作类型。例如，consoleMessage 操作类型不具有相关阻塞时间。如果指定的值不适用于操作类型，则该值将被忽略。

示例

• 使用以下过滤器来查看所有运行时间大于秒钟的操作：

executionTime>5 s

使用以下过滤器来查看所有运行时间大于 5 秒钟的 SQL 语句：

executionTime>5 s type=ExecuteStatement

使用以下过滤器来查看所有运行时间大于 5 秒钟的 SQL 语句（包括预准备（参数化的）语句）：

executionTime>5 s type=ExecuteStatement,ExecutePreparedStatement

• 使用以下过滤器来查看阻塞时间大于毫秒的语句：

blockedTime>10 ms

使用以下过滤器来查看当前处于阻塞状态的语句：

state=blocked

• 使用以下过滤器查看因出错而执行失败的语句：
• 使用以下过滤器来查看用户执行的操作：
• 使用以下过滤器来查看通过进行连接的操作：
• 使用以下过滤器来查看仅由名为的应用程序引起的操作。
• 使用以下过滤器来查看那些仅在当天至之间运行的操作：

severity=error

user=dba

connection=91

appinfo.execontains mlsrv 

between 9:15 and 9:20 

使用以下过滤器来查看那些仅在 2015 年 1 月 31 日 9:15 至 9:20 之间运行的操作：

between 2015-01-31 9:15 and 2015-01-31 9:20 

• 要查看引用表的语句，请打开语句选项卡，然后使用以下过滤器：Customers。

Is MacOSX 10.11.x supported by SQLA 17 as platform?

As the Internet of Things becomes an even greater reality, capturing data in environments outside of traditional data centers – out in the real world – has become increasingly vital.  With the latest release of SAP SQL Anywhere suite, companies can securely capture, store, process, access and feed data into enterprise applications from remote workplaces with low bandwidth or intermittent connections, such as factory floors, retail stores, restaurants, remote facilities, satellite offices and even vehicles in motion.

Developers in some of the world’s largest and most well-known companies are using SAP SQL Anywhere database and synchronization technology to rapidly design, build, and deploy database-powered applications for mobile and remote environments where there is limited or no IT support.

And now we’re making it easier than ever to buy.

SQL Anywhere versions 16 and 17 are now available for purchase on theSAP Digital Store. You can now use a credit card to purchase the solution, download and use in minutes.

For more information about version 16 and 17 of SQL Anywhere visit SAPStore.com:

SAP SQL Anywhere (v16)

SAP SQL Anywhere (v17)

There’s a reason why SAP SQL Anywhere is one of the most trust embedded databases in the world. Join over 20,000 developers in some of the world’s largest and most well-known companies today.

You do not have to look very far to see industry predictions of the huge number of devices that will be connected in the next few years, and the enormous amount of data they will be produced. With data volumes in the petabytes being predicted, there has been a lot of focus on the big data problem, and how technologies like HANA can be used to centrally mine business value out of these new sources of data.

However, when talking of data sizes in the petabytes, it is not easy to dismiss the question of how the data will move from the sensors into the cloud. There will be some environments that simply do not have the fat, fast network pipes required to send high volumes of data in real-time (think off-shore oil rigs and mines). In these environments the data will need to be stored, analyzed, and acted upon out at the edge near the sensors. Even for environments where all of the data will eventually be stored in the cloud, the real-time requirements of an application may not allow for the additional latency that a round-trip to the cloud will need (think slow and unreliable satellite connections).

For IoT applications that have these requirements, SAP has data management products that have been specifically designed for running at the edge. These do not replace the main IoT processing that is done in HANA, but rather augments it with additional capabilities. Two of these technologies are SAP SQL Anywhere, and SAP Streaming Lite.

SAP SQL Anywhere is a database that has been specifically designed to run in locations outside of the traditional data center, where there is no database administrator. This has made it very suitable for embedding in applications that run in edge location such as water towers and kiosks. SQL Anywhere can embed so well that it is sometimes called an “invisible database”.  With millions of active deployments, it is likely you have used some equipment or system that embedded SQL Anywhere without even knowing it. In addition to the basic functions of storing IoT data, SQL Anywhere provides a rich set of tools for doing data analysis on the edge. Despite the small footprint of less than 20MB, SQL Anywhere provides enterprise features like native spatial queries, full-text search, and OLAP functions.

In some environments, the data volumes and real-time requirements are so high that action must be taken immediately, even before the data reaches the database. For these situations, a solution designed specifically for analyzing high volume and high velocity streams of data is ideal. SAP Streaming Lite is a stream processor for the edge. Like SQL Anywhere, it is designed to run on the types of resource-constrained devices that will deployed in these environments. Streaming Lite is able to take in multiple streams of sensor data and perform queries over them including filtering, calculating moving averages, and detecting anomalies that require attention.

Although SAP SQL Anywhere and SAP Streaming Lite can be used independently, they become a true powerhouse at the edge when they are combined. SAP Streaming Lite becomes the front line for the incoming sensory data. In the case of large data volumes, SAP Streaming Lite can either filter, or average the data to reduce the total amount of data that must be passed on for further processing. In the case of real-time requirements, SAP Streaming Lite can scan the incoming data looking for specific conditions, and raise events to the edge application. Once the data has passed through Streaming Lite, the augmented data can be durably stored in SAP SQL Anywhere for further analysis and querying by the edge application.  The data flow can go the other way as well; historic data from SAP SQL Anywhere can feed back into SAP Streaming Lite to provide historic context and constants.

Although the data may be analyzed at the edge, it may still need to be propagated back to the cloud for the further analysis and auditing. Both edge components have complementary technologies in the data center to facilitate moving the data in and out of HANA. For real-time data, Streaming Lite can connect to HANA Smart Data Streaming to pass the augmented data on for further stream processing in the data center. For historic data, SQL Anywhere can connect to HANA Remote Data Sync to synchronize with HANA whenever a connection is available.

To get started with SQL Anywhere, please download the free SQL Anywhere Developer Edition. The developer edition is fully-featured, not time limited, and free for development use on your desktop. 

For more information on Streaming Lite, which is available as a remote deployment option for SAP HANA smart data streaming, see the Streaming Developer Center.  Users that want to get started can sign up for the SAP HANA Developer Edition, which now includes smart data streaming, and take advantage of this set of tutorials for putting streaming lite into action.