求解这个数据库问题

Posted 2023-04-04

错误原因：由于文件不可访问，或者内存或磁盘空间不足，所以无法打开数据库 'keshe'。有关详细信息，请参

我是用vs2008开发的程序，使用的sql最开始是vs自己安装的sql，后面要更求备份数据库，于是安装了一个sql servere manafement ，把原本安装目录下的数据库剪切到另一个位置，重新在vs中链接数据库，数据操作可以正常完成。但是在management中附加这个数据库后，可以备份数据库，但是在用.net运行备份数据库后，会出现如上错误，。求大婶知道。

还有这个错误：（.net运行时）

错误原因：无法打开物理文件 "C:\App_Data\keshe.mdf"。操作系统错误 32:"32(另一个程序正在使用此文件，进程无法访问。)"。无法打开物理文件 "C:\App_Data\keshe_log.ldf"。操作系统错误 32:"32(另一个程序正在使用此文件，进程无法访问。)"。由于文件不可访问，或者内存或磁盘空间不足，所以无法打开数据库 'keshe'。有关详细信息，请参阅 SQL Server 错误日志。 BACKUP DATABASE 正在异常终止。文件激活失败。物理文件名称'C:\App_Data\keshe_log.ldf'可能不正确。

在.net运行出错后，再次在management里运行查询
backup database keshe to disk='d:krfghk.bak'

出错：消息 945，级别 14，状态 2，第 1 行
由于文件不可访问，或者内存或磁盘空间不足，所以无法打开数据库 'keshe'。有关详细信息，请参阅 SQL Server 错误日志。
消息 3013，级别 16，状态 1，第 1 行
BACKUP DATABASE 正在异常终止。

参考技术A 你的数据库有别的程序打开占用着 参考技术B 描述的有点晕，看不懂，你把文件脱机了然后重新附加下再看看。

求解具有不连续输入/强制数据的 ODE

【中文标题】求解具有不连续输入/强制数据的 ODE

【英文标题】：Solve ODEs with discontinuous input/forcing data

【发布时间】：2015-11-20 10:11:55

【问题描述】：

我正在尝试在 Python 中解决耦合的一阶 ODE 系统。我是新手，但到目前为止，来自 SciPy.org 的 Zombie Apocalypse example 提供了很大的帮助。

我的一个重要区别是用于“驱动”我的 ODE 系统的输入数据在不同的时间点突然发生变化，我不确定如何最好地处理这个问题。下面的代码是我能想到的最简单的例子来说明我的问题。我很欣赏这个例子有一个简单的解析解，但我实际的 ODE 系统更复杂，这就是为什么我试图理解数值方法的基础知识。

简化示例

考虑一个底部有孔的桶（这种“线性水库”是许多水文模型的基本组成部分）。桶的输入流量为R，孔的输出为Q。 Q 假定与桶中水的体积成正比，V。比例常数通常写成，其中T是商店的“驻留时间”。这给出了一个简单的 ODE 形式

实际上，R 是观察到的每日降雨总量的时间序列。 在每天，降雨率假设是恒定的，但在天之间降雨率突然变化（即R是一个不连续 时间函数）。我试图了解这对解决我的 ODE 的影响。

策略 1

最明显的策略（至少对我而言）是在每个降雨时间步长内分别应用 SciPy 的 odeint 函数。这意味着我可以将 R 视为一个常数。像这样的：

import numpy as np, pandas as pd, matplotlib.pyplot as plt, seaborn as sn
from scipy.integrate import odeint

np.random.seed(seed=17)

def f(y, t, R_t):
    """ Function to integrate.
    """
    # Unpack parameters
    Q_t = y[0]

    # ODE to solve
    dQ_dt = (R_t - Q_t)/T

    return dQ_dt

# #############################################################################
# User input   
T = 10      # Time constant (days)
Q0 = 0.     # Initial condition for outflow rate (mm/day)
days = 300  # Number of days to simulate
# #############################################################################

# Create a fake daily time series for R
# Generale random values from uniform dist
df = pd.DataFrame('R':np.random.uniform(low=0, high=5, size=days+20),
                  index=range(days+20))

# Smooth with a moving window to make more sensible                  
df['R'] = pd.rolling_mean(df['R'], window=20)

# Chop off the NoData at the start due to moving window
df = df[20:].reset_index(drop=True)

# List to store results
Q_vals = []

# Vector of initial conditions
y0 = [Q0, ]

# Loop over each day in the R dataset
for step in range(days):
    # We want to find the value of Q at the end of this time step
    t = [0, 1]

    # Get R for this step
    R_t = float(df.ix[step])   

    # Solve the ODEs
    soln = odeint(f, y0, t, args=(R_t,))

    # Extract flow at end of step from soln
    Q = float(soln[1])

    # Append result
    Q_vals.append(Q)

    # Update initial condition for next step
    y0 = [Q, ]

# Add results to df
df['Q'] = Q_vals

策略 2

第二种方法是简单地将所有内容提供给odeint，并让它处理不连续性。使用与上述相同的参数和 R 值：

def f(y, t):
    """ Function used integrate.
    """
    # Unpack incremental values for S and D
    Q_t = y[0]

    # Get the value for R at this t
    idx = df.index.get_loc(t, method='ffill') 
    R_t = float(df.ix[idx])       

    # ODE to solve
    dQ_dt = (R_t - Q_t)/T

    return dQ_dt

# Vector of initial parameter values
y0 = [Q0, ]

# Time grid
t = np.arange(0, days, 1)

# solve the ODEs
soln = odeint(f, y0, t)

# Add result to df
df['Q'] = soln[:, 0]

这两种方法都给出了相同的答案，如下所示：

然而，第二种策略虽然在代码方面更紧凑，但它远比第一种慢。我想这与 R 中的不连续性导致odeint 出现问题有关吗？

我的问题

策略 1 是这里最好的方法，还是有更好的方法？ 策略 2 是个坏主意吗？为什么这么慢？

谢谢！

【参考方案1】：

1.) 是的

2.) 是的

两者的原因：Runge-Kutta 求解器期望 ODE 函数的可微阶至少与求解器的阶一样高。这是需要的，以便存在给出预期误差项的泰勒展开。这意味着即使是 1 阶欧拉方法也需要一个可微的 ODE 函数。因此不允许跳跃，可以在 1 阶中容忍扭结，但在高阶求解器中则不能。

对于具有自动步长调整的实现尤其如此。每当接近不满足微分阶数的点时，求解器就会看到一个僵硬的系统并将步长驱向 0，这会导致求解器变慢。

如果您使用具有固定步长且步长为 1 天几分之一的求解器，则可以组合策略 1 和 2。然后，当日轮流的采样点作为（隐式）重新启动点使用新的常数。

【讨论】：

谢谢@LutzL！在性能方面，您认为是否值得研究组合策略？还有其他优点吗？到目前为止，我一直假设自适应求解器在某种程度上“更好”，但这可能是幼稚的。我在 SciPy 的 ODE 求解器中看不到固定步长选项，但也许设置 min_step = max_step （或非常接近的值）会达到同样的效果？

我认为如果策略 1 对你有效，那么你不应该改变它。我希望它已经（接近）最优。在混合情况下，您需要付出额外的努力来定义阶跃函数，然后（可能）解释结果。 -- 像 rk4 这样的固定步长求解器可能被认为在 scipy 中提供的过于简单，您应该可以在此站点上找到许多实现示例。