标签: errors

我正在使用 SQL Server 2008 Sp3

最近我在 SQL 日志中遇到错误：

错误：18059，严重性：20，状态：1
。连接已被删除，因为打开它的主体随后假定了一个新的安全上下文，然后尝试在其模拟的安全上下文下重置连接。不支持此方案。请参阅联机丛书中的“模拟概述”。

我通过 Profiler 找到了相关的原始服务器和应用程序。

我搜索并发现有人说我需要更改应用程序连接字符串中的连接池。

以下是相关Web.Config文件：

<?xml version="1.0"?>
<appSettings>
    <add key="Main.ConnectionString" value="Data Source=db-002\db2;Initial   
Catalog=APPDB;TRUSTED_CONNECTION=YES"/>
    <add key="ConnectionHash" value="==QMr1meolHO3YWdTNFOzcTO"/>
    <add key="Database" value="[APPDB]"/>
    <add key="UseApprole" value="True"/>
</appSettings>

我在我们的测试环境中将其更改为以下内容：

<?xml version="1.0"?>
<appSettings>
    <add key="Main.ConnectionString" value="Data Source=db-002\db2;Initial 
Catalog=APPDB;TRUSTED_CONNECTION=YES;Pooling=false"/>
    <add key="ConnectionHash" value="==QMr1meolHO3YWdTNFOzcTO"/>
    <add key="Database" value="[APPDB]"/>
    <add key="UseApprole" value="True"/>
</appSettings>

我已经重置了应用程序、服务和 IIS。检查应用程序，它的工作原理。

有一段时间我没有再收到这些错误，但 3 小时后它们又恢复了。

谁能给我一个想法我能做什么？

SQL Server 2005 SP4 32 位

我有一个每晚运行的 DBCC CHECKDB 作业。昨晚，在工作开始后不久，我收到了以下错误。数据库未处于可疑模式，当我现在运行它时 CHECKDB 恢复干净。数据库是完全可访问的。我应该担心吗？我不想在这一点上回到备份。

 2013-04-02 02:10:55.53 spid56      Error: 1203, Severity: 20, State: 1.
 2013-04-02 02:10:55.53 spid56      Process ID 56 attempted to unlock a resource it
                                    does not own: PAGE: 34:1:388664. Retry the 
                                    transaction, because this error may be caused 
                                    by a timing condition. If the problem persists, 
                                    contact the database administrator.
 2013-04-02 02:10:55.58 spid56      Error: 3314, Severity: 17, State: 3.
 2013-04-02 02:10:55.58 spid56      During undoing of a logged operation in 
                                    database 'MY_DATABASE_NAME', …

我做了一个mysqldump将所有数据库转储到一个.sql文件中，然后安装了一个 mariadb 服务器。安装后没有错误。但是在恢复数据库后，我开始观察到以下两个错误：

[错误] 表 mysql.event 的定义不正确：位置 14 处的预期列 'sql_mode' 的类型设置为 ('REAL_AS_FLOAT','PIPES_AS_CONCAT','ANSI_QUOTES','IGNORE_SPACE','IGNORE_BAD_TABLE_OPTIONS','ONLY_FULL_GROUP_TRABUNTIONED' ','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_FIELD_OPTIONS','MYSQL323','MYSQL40','ANSI', 'NO_AUTO_VALUE_ON_ZERO'、'NO_BACKSLASH_ESCAPES'、'STRICT_TRANS_TABLES'、'STRICT_ALL_TABLES'、'NO_ZERO_IN_DATE'、'NO_ZERO_DATE'、'INVALID_DATES'、'ERROR_FOR_DIVISION_、'_AUTOZERO_CREATEHIGH_NOT_PRECEDENCE','NO_ENGINE_SUBSTITUTION','PAD_CHAR_TO_FULL_LENGTH'), 发现类型集('REAL_AS_FLOAT','PIPES_AS_CONCAT','ANSI_QUOTES','IGNORE_SPACE','NOT_USED','GROUP_SUBTRAN_CREED','ONLY_BTRAIN_CREED','ONLY_BTRAIN_FLOAT' ','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_FIELD_OPTIONS','MYSQL323','MYSQL40','ANSI','NO_AUTO_VALUE_ON_ZERO','NO_CAPACKESSL' 'STRICT_TRANS_TABLES','STRICT_AONLY_FULL_GROUP_BY','NO_UNSIGNED_SUBTRACTION','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_SQLMY_OPTIONS','NO_SQLMYMY_OPTIONS3' ,'ANSI','NO_AUTO_VALUE_ON_ZERO','NO_BACKSLASH_ESCAPES','STRICT_TRANS_TABLES','STRICT_AONLY_FULL_GROUP_BY','NO_UNSIGNED_SUBTRACTION','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_SQLMY_OPTIONS','NO_SQLMYMY_OPTIONS3' ,'ANSI','NO_AUTO_VALUE_ON_ZERO','NO_BACKSLASH_ESCAPES','STRICT_TRANS_TABLES','STRICT_A
[错误] 事件调度程序：初始化系统表时出错。禁用事件调度程序。

看起来mysql.event表格中的某些东西被覆盖了。我没有创建任何事件，所以我没想到这里会受到任何影响。应该怎么做才能消除这个错误？

我似乎无法弄清楚是什么导致了 I/O 错误：

$sqlite3 db.sqlite < data.sql 
(3850) disk I/O error
Error: near line 2: disk I/O error
(3850) disk I/O error
Error: near line 3: disk I/O error
(3850) disk I/O error
Error: near line 5: disk I/O error
(3850) disk I/O error
Error: near line 8: disk I/O error
(3850) disk I/O error
Error: near line 9: disk I/O error

参见下面data.sql的内容

$ less data.sql
.log stderr 
PRAGMA synchronous = OFF;
PRAGMA journal_mode = MEMORY;
BEGIN TRANSACTION;
CREATE TABLE …

我已经在 Windows 7 机器上使用 PostgreSQL 9.6 配置了 PgBouncer。以下是 pgbouncer 配置设置；

[数据库]

测试=主机=127.0.0.1 端口=5432 dbname=master_db 用户=postgres 密码=test123

[保镖]

日志文件 = C:\Program Files (x86)\PgBouncer\log\pgbouncer.log
pidfile = C:\Program Files (x86)\PgBouncer\log\pgbouncer.pid
监听地址 = *
监听端口 = 6432
验证类型 = md5
auth_file = C:\Program Files (x86)\PgBouncer\etc\userlist.txt
admin_users = postgres
stats_users = postgres
最大客户端连接数 = 100
默认池大小 = 20

用户列表文件

“测试用户”“巴查”

当我尝试使用 pgbouncer 连接到数据库时，通过此命令；

psql -h 127.0.0.1 -p 6432 -U test_user master_db

我收到这个错误

psql：错误：client_login_timeout（服务器关闭）
psql：错误：pgbouncer 无法连接到服务器

我怎么解决这个问题？

我的trackedinfo数据库中有一个表 ( )，它具有以下列（通过运行获得的列PRAGMA table_info(trackedinfo);）

问题是，即使该列sendok存在，当对具有该字段的数据库运行查询时，它也会引发错误。

示例查询：

SELECT * FROM trackedinfo WHERE sendok IS NULL;
SELECT sendok FROM trackedinfo;

错误：

SQLITE_ERROR: SQL error or missing database (no such column: sendok)

但是，如果我运行一个选择所有字段的查询，它会给我带来以下信息sendok：

这是CREATE数据库的命令：

CREATE TABLE trackedinfo
(
    id INTEGER PRIMARY KEY,
    date_time_start TEXT,
    date_time_end TEXT,
    tracked_name TEXT,
    tracked_origin TEXT,
    tracked_maker TEXT,
    tracked_version TEXT,
    tracked_type TEXT,
    sendok TEXT,
    tracked_id TEXT
);

它也发生在列 tracked_id

我通过执行获得的信息 .schema trackedinfo

CREATE TABLE IF NOT EXISTS "trackedinfo" ("id" …

当我收到错误时，他们中的一些人有一个HY代码，

ERROR 2002 (HY000): 无法通过 socket '/var/run/mysqld/mysqld.sock' 连接到本地 MySQL 服务器（2“没有这样的文件或目录”）

HY000在上面的上下文中是什么。有关错误消息中的另一个示例，请参阅此问题HY000

这个查询有问题：

SELECT *
FROM Sales.SalesOrderDetail sod
JOIN Sales.SalesOrderHeader soh
ON sod.SalesOrderID = soh.SalesOrderID--- adventureworks db

警告

表达式中的类型转换 (CONVERT(nvarchar(23),[soh].[SalesOrderID],0​​)) 可能会影响查询计划选择中的“CardinalityEstimate”

我使用 PostgreSQL 13（最新的 dockerized）进行了简单的设置：

    CREATE TABLE stop (
      id INT UNIQUE,
      name TEXT,
      PRIMARY KEY(id)
    );

    CREATE TABLE line (
      id INT UNIQUE,
      name TEXT,
      PRIMARY KEY(id)
    );

    CREATE TABLE line_stops_sequence(
      id SERIAL PRIMARY KEY,
      line INT,
      stop INT,
      CONSTRAINT fk_line FOREIGN KEY(line) REFERENCES line(id),
      CONSTRAINT fk_stop FOREIGN KEY(stop) REFERENCES stop(id)
    );

当我启动下面这句话时

INSERT INTO line(id, name) VALUES (1, 'Line 1');
INSERT INTO stop(id, name) VALUES (2, 'Stop 2');
INSERT INTO line_stops_sequence(line, stop) VALUES (1,1), (1,2) ON CONFLICT ON CONSTRAINT …

我们在 DEV/QA/PROD SQL 2017 Enterprise 服务器上遇到了看似随机的错误 824。服务器运行几乎相同的代码，通过 ETL 流程将相同的日常文件摄取到我们的数据仓库中。这些错误是在 2022 年 5 月左右首次发现的，但由于日志清理，我们无法确定（供应商提供的）ETL 流程是否正在捕获这些错误、记录警告并继续处理而不是失败！

DEV/QA 已修补到 CU30（最新的 CU）——这种情况仍然存在。CU22 的生产落后了几个补丁，计划在未来几周内进行修补。

例子：

SQL Server 检测到基于逻辑不一致的 I/O 错误：校验和不正确（预期为 0xc30164e7；实际为 0x9f2bc675c）。它发生在读取文件“H:\tempdb_mssql_6.ndf”中偏移量 0x0000027de40000 处的数据库 ID 2 中的页 (7:1306400) 期间。

如前所述，这种情况在我们所有的环境中都是随机发生的。所有服务器都是虚拟化的。DEV/QA 都使用相同的 SAN。生产位于不同数据中心的单独 SAN 上。我没有 SAN 设备品牌/型号的详细信息。

在大多数情况下，当发生这种情况时，它似乎主要在 tempdb 中（但并非总是如此）。此外，suspect_pages 通常是空的。这种情况似乎在周六发生得更频繁，因为我们连续发生了 3-4 次。

另请注意，错误中列出的预期/实际值通常是相同的 - 但并非总是如此。

还注意到，特定的存储过程似乎更容易引发此错误，但是，它已经发生在 ETL 作业中的多个其他位置，再次影响不同的数据库。似乎触发此错误的存储过程最常添加一个 PERSISTED 计算列，然后添加一个基于该计算列的 ROW_NUMBER() - 到 5 个表，大小范围从 200K 到 750 万行。我们昨天（在 QA 中）修改了此过程，以限制使用 ROW_NUMBER() 值更新的行数（仅当 rownum=1 时），并将更新从一次性全部更改为 25K 批量方法。今天在 QA 中再次发生该错误 - 因此我们删除了计算列上的 PERSISTED 选项。我们实际上正在尝试在质量检查中阻止这种情况，因为它似乎受到的影响最大。

DBCC CHECKDB …