CÁCH FIX LỖI SQL SERVER DATABASE IN RECOVERY MODE

CÁCH FIX LỖI SQL DATABASE IN RECOVERY MODE

Ngữ cảnh lỗi.

Máy chủ đang chạy SQL Server bị ngắt điện đột ngột sẽ bị lỗi databases vì dữ liệu đang ghi log chưa checkpoint cho nên sẽ bị in recovery mode hoặc recovery pending.

Kết quả chúng ta không thể truy cập như hình.

Kiểm tra tình trạng hay trạng thái databases

SELECT name, state_desc from sys.databases

Dùng lệnh bên dưới để kiểm tra

Một số trạng thái của dữ liệu như sau:

  • ONLINE
  • RESTORING
  • RECOVERING
  • RECOVERY_PENDING
  • SUSPECT
  • EMERGENCY
  • OFFLINE
  • COPYING
  • OFFLINE_SECONDARY

Trạng thái chúng ta đang bị là Recovering

Nguyên nhân gây lỗi

Một số nguyên nhân sư sau:

  • Máy chủ SQL bị tắt do lỗi. Nó có thể là phần cứng, sức mạnh hoặc thứ gì khác.
  • Đĩa có thể bị thiếu.
  • Tệp MDF hoặc LDF có thể bị thiếu
  • Đĩa đầy
  • Quá trình nâng cấp SQL không diễn ra tốt đẹp hoặc bị gián đoạn.
  • Sự thay đổi lớn đang được đưa ra nhưng có điều gì đó đã thất bại giữa chừng, chẳng hạn như những thay đổi đối với tính năng FileStream.
  • Tệp LDF (nhật ký) bị hỏng.
  • Tệp MDF (dữ liệu) bị hỏng. Tệp db của tệp MDF có thể bị hỏng vì nhiều lý do như sự cố đĩa hoặc SAN, lỗi phần cứng, vi rút, v.v.
  • Máy chủ đã khởi động lại và có gì đó đã thay đổi, chẳng hạn như thiếu đĩa hoặc thư mục hoặc thiếu quyền.
  • Cryptoware đã mã hóa các tệp SQL của bạn.

Cách xử lý

Trường hợp 1: Set Database state to ONLINE

Lỗi do disk full thì không thể set online cũng như start chúng ta phải mở rộng disk trước khi thực hiện.

ALTER DATABASE ‘AdventureWorks2019’ SET ONLINE;

DBCC CHECKDB(‘AdventureWorks2019’) WITH NO_INFOMSGS;

Trường hợp 2: Rebuilding lại log file và detach và attach file

Nôm na là setup mode emergency, sau đó detach, attach lại.

ALTER DATABASE [AdventureWorks2019] SET EMERGENCY;

ALTER DATABASE [AdventureWorks2019] set MULTI_USER;

EXEC sp_detach_db '[AdventureWorks2019]';

EXEC sp_attach_single_file_db @DBName = '[AdventureWorks2019]', @physname = N'MDF_FILE_FULL_PATCH';

Trường hợp 3: Initiate DBCC CHECKDB with REPAIR option

  • Admin bị và xử lý theo cách 3 sẽ ok chúng ta có thể rơi vào từng trường hợp để test nhé.
  • Trường hợp này có thể bị mất dữ liệu, tốt nhất có thể chuẩn bị bản backup, trước khi thao tác.
  • Hãy chắc chắn rằng bạn có một bản sao lưu. Đừng làm điều này trên db DUY NHẤT mà bạn có, vì sau khi sửa chữa hoàn tất, bạn có thể mất dữ liệu và bạn có thể không thích những gì đã bị mất!
  • DBCC CHECKDB với tùy chọn SỬA CHỮA là một giao dịch được ghi lại và có thể phục hồi. Điều đó có ý nghĩa gì với bạn? Điều đó có nghĩa là nếu bạn gói DBCC CHECKDB với REPAIR vào một giao dịch (thực thi BEGIN TRANSACTION trước khi chạy lệnh) và bạn không thích kết quả cuối cùng, thì bạn có thể hoàn nguyên giao dịch và quay lại nơi bạn đã bắt đầu. Bằng cách đó, bạn sẽ có thể Khôi phục các thao tác sửa chữa nếu cần thiết.
  • 3.1. REPAIR_REBUILD
  • Có nhiều cấp độ sửa chữa khác nhau. Hãy thử bắt đầu với “REPAIR_REBUILD”, thực hiện sửa chữa mà không có khả năng mất dữ liệu:
    1. Đặt cơ sở dữ liệu ở chế độ một người dùng
    2. Chạy DBBC CHECKDB với “REPAIR_REBUILD”
    3. Đặt cơ sở dữ liệu thành “online” và kích hoạt lại chế độ nhiều người dùng

Câu lệnh bên dưới lưu ý thay databases của các bạn vào nhé:

ALTER DATABASE DATABASENAME SET SINGLE_USER;

DBCC CHECKDB (DATABASENAME, REPAIR_REBUILD) WITH NO_INFOMSGS, ALL_ERRORMSGS;

ALTER DATABASE [DATABASENAME] SET ONLINE;

ALTER DATABASE [DATABASENAME] SET MULTI_USER;

Nếu sửa chữa thành công, cơ sở dữ liệu có thể được đặt lại về chế độ nhiều người dùng. Nếu không, mức độ sửa chữa “REPAIR_ALLOW_DATA_LOSS” là tùy chọn tiếp theo.

  • 3.2. REPAIR_ALLOW_DATA_LOSS

Bước này có thể bị mất dữ liệu nhé 😊

  1. Đặt cơ sở dữ liệu ở chế độ Khẩn cấp
  2. Chạy DBBC CHECKDB với “REPAIR_ALLOW_DATA_LOSS”
  3. Đặt cơ sở dữ liệu thành “ONLINE” và kích hoạt lại chế độ nhiều người dùng

Code Sql:

ALTER DATABASE [DATABASENAME] SET EMERGENCY;

ALTER DATABASE [DATABASENAME] SET SINGLE_USER;

DBCC CHECKDB (DATABASENAME,REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;

ALTER DATABASE [DATABASENAME] SET ONLINE;

ALTER DATABASE [DATABASENAME] SET MULTI_USER;

Check data

Kiểm tra lại trạng thái

Trường hợp 4: Restoring from Backup

Trường hợp này là sau cùng, các trường hợp trên không cứu được chúng ta buộc phải khôi phục từ backup.

Ngoài các công cụ sẵn có của MSSQL chúng ta có thể sử dụng áp thứ 3 trả tiền license để khôi phục hoặc sửa chữa:

  • SysInfo Tools MS SQL Database Recovery Software,
  • Stellar Repair for MS SQL,
  • DiskInternals MSSQL Recovery Software
  • DataNumen SQL Recovery
  • Recovery for SQL Server
    Aryson SQL Database Recovery Tool
  • ApexSQL Recover
  • Recoveryfix for SQL Database Recovery
  • Recovery Toolbox for SQL Server
  • SysTools SQL Recovery Software

Chúc các bạn thành công trong công việc cứu dữ liệu

Phương nguyễn viết

Tài liệu tham khảo:

https://red9.com/blog/how-to-fix-recovery-pending-state-in-sql-server/

CÁCH UPGRADE VEEAM V12 KB LÊN VEEAM V12 KB4420

CÁCH UPGRADE VEEAM V12 KB LÊN VEEAM V12 KB4420

Chuẩn bị source KB

Link tải

https://www.veeam.com/kb4420 Tải iso file path

Filename: VeeamBackup&Replication_12.0.0.1420_20230718.zip

MD5: 1A89F6CD6E4D64F546E773548FA0FD63

SHA1: B08F58A9A2E51BCE2C5F7876C57B4E33AADEB9B0

Giải nén file zip

Setup

Stop All Services Veeam Backup & Replication

Hoặc chạy Powershell cho nhanh:

get-service veeam* stop-service

Stop-Service -Name Veeam*

Trước khi chạy backup file license lại nhé.

Khởi động lại Server Veeam.

Cập nhật các remote compoment

Rename file VeeamLicense.dll->old.

C:\Program Files\Common Files\Veeam

VeeamLicense.dll > to > VeeamLicense.dll.old
[ available in C:\Program Files\Common Files\Veeam\ ]

[ available in C:\Program Files\Common Files\Veeam\Backup And Replication ]

Sau khi udpate xong chúng ra trả lại file Veeamlicense.dll

  • C:\Program Files\Common Files\Veeam
  • C:\Program Files\Common Files\Veeam\Backup And Replication

Công việc tiếp theo sẽ upgrade và scan lại reposibilites, các module upgrade.

Chúc các bạn thành công

Phương Nguyễn Viết

Optimal Window’s OS page file settings for SQL Server

Windows OS page file not optimal

What is the Windows OS page file?

This file is a form of virtual memory.

When your memory ram becomes full, Windows moves data from your memory RAM to your hard drive, placing it in the page file (also known as the swap file).

By the way, this check is a part of our SQL Server Health Check.

You never want your SQL Server to start paging.

SQL Server tends to go pear-shaped when it’s memory is paged to disk.

Optimal page file size settings for SQL Server

By default, the page file is auto managed by Windows.

You don’t want to trust the management of page file to Windows, as it won’t do what is optimal for SQL Server.

Page file sizing depends on the system crash dump setting requirements and the peak usage or expected peak usage of the System commit charge.

Both considerations are unique to each System, even for identical systems.

The old rules of thumb (Page file size = RAM * 1.5 or RAM * 2) makes no sense in modern systems, where the logic should be: the more RAM you have, the less you need paging file.

So, how should you size your Page File?

It depends on the specific workload and the type of server.

When sizing the page file, we need to consider our application’s memory needs and crash dump settings.

A good point of start is set 8-12 GB size for Kernel Memory dump on System with up to 256GB RAM.

You can learn more about it here.

How can I change the windows file size?

You can configure the page file by using System Properties:

  1. Run sysdm.cpl;
  2. Go to Advanced ;
  3. Select Settings under Performance ;
  4. Go to Advanced (again);
  5. Change under Virtual Memory.

Source Internet

HA Agent – Fault Domain Manager (FDM) overview

Fault Domain Manager (FDM)

Most important component in HA cluster is FDM (Fault Domain Manager) agent. It is responsible for some of following tasks:

  • Communicating host resource information,
  • VM states and HA properties to other hosts in the cluster.
  • Handles heartbeat mechanisms
  • VM placement
  • VM restarts
  • logging

As soon you enable the vSphere HA in a cluster, the Fault Domain Manager (FDM) agent service runs on each hosts in the cluster. There is one Master and other slave hosts in a vSphere cluster. Fault Domain Manager (FDM) agent is installed on all the slave or subordinate hosts that is used to communicate with the FDM of a master host.

FDM is installed into the ESXi hosts at /opt/vmware/fdm and stores its configuration files at /etc/opt/vmware/fdm.

FDM.log location and usage..

The log file named fdm.log is stored under /var/log/. If there is issue occurred in your environment, fdm.log is very helpful in order to troubleshoot it. For example if VMs are restarted without any known reason, this log file will show when and why this happened, for instance it could be due to host, network or storage failure.

How master host is elected?

An agent picks up the master host during election process (approximately 15 seconds) which is taken place between all the hosts. The host that can access the greatest no of datastores is elected as a master host. If more than one host sees the same no of datastores, the election process determines the master host by using the host Managed Object ID (MOID) assigned by vCenter Server

What happen if FDM fails:

when FDM runs it spawns a watchdog process, so in case of agent failure, the watchdog restart it.

Does vCenter talks to slave Hosts agents?

Yes when vCenter scanning for a HA master,
when a host is reported as isolated or partitioned, or
if the existing master informs vCenter that it cannot reach a slave agent.

How FDM communicates ?

FDM agent uses both the management network and storage devices for communication. All the HA agents (candidates for master) communicate with each other over the management network during election process by using User Datagram Protocol (UDP). All network connections are point-to-point. And once the mater host is elected, the master host and subordinate hosts communicate using secure TCP.

Source https://babarmunir.wordpress.com/2021/04/21/ha-agent-fault-domain-manager-fdm-overview/

Thông tin bản cập nhật bảo mật (SU) Tháng 08/2023 Exchange Server

Thông tin bản cập nhật bảo mật(SU) Tháng 08/2023 Exchange Server

Ngày 08/08/2023 Microsoft đã phát hành Bản cập nhật bảo mật(SU) cho các lỗ hổng được tìm thấy: EX2016 CU23, EX2019 CU12,CU13

1/ CVE-2023-21709

Điểm nỗi bật bản này là giải quyết được lỗ hổng CVE-2023-21709 (khai thác TokenCacheModule trong IIS). Các bước cần thiết để giải quyết CVE-2023-21709 tốt nhất cài bản vá trước rồi hãy chạy script CVE-2023-21709.ps1

Cài đặt bản vá ngay lập tức để bảo vệ Exchange Server khỏi rủi ro có thể bị tổn thương:

Step 1. Cài bản vá  bảo mật tháng 8/2023 cho Exchange Server 2016/2019-> link

Step 2. Reboot the Exchange Server

Step 3. Run the CVE-2023-21709.ps1 script này bản chất sẽ remove tokencachemolude trong IIS-> link

Các CVE bên dưới được xử lý bằng Bản cập nhật bảo mật:

 CVE-2023-21709

CVE-2023-35368

CVE-2023-35388

CVE-2023-38181

CVE-2023-38182

CVE-2023-38185

2/ Hỗ trợ thay đổi thuật toán mã hóa mặc định trong Microsoft Purview Information Protection

Phần này chỉ áp dụng cho những khách hàng của MS sử dụng Exchange Server và Azure hoặc Dịch vụ quản lý quyền AD (RMS). Nếu bạn không biết đó là gì, những thay đổi về mã hóa Exchange Online CBC sẽ không áp dụng.

Bật hỗ trợ cho nội dung được mã hóa AES256-CBC trong Exchange Server đối với khách hàng nào sử dụng dịch vụ Azue hoặc AD (RMS) của MS.

Như đã thông báo trong phần Thay đổi thuật toán mã hóa trong bài đăng trên blog Microsoft Purview Information Protection, các SU Exchange Server tháng 8 năm 2023 chứa các bản cập nhật cho phép khách hàng sử dụng Exchange Server tại chỗ tiếp tục giải mã nội dung được bảo vệ bởi nhãn nhạy cảm Purview hoặc Dịch vụ quản lý quyền Active Directory. Vui lòng xem lại bài đăng trên blog đó để biết chi tiết và lịch trình, đồng thời đọc hỗ trợ AES256-CBC cho tài liệu Microsoft 365.

Nếu tổ chức của bạn bị ảnh hưởng bởi thay đổi này, sau khi cài đặt SU tháng 8 trên máy chủ Exchange của bạn, hãy xem bài viết về cách bật hỗ trợ mã hóa AES256-CBC. Xin lưu ý – bước này không cần thiết trừ khi máy chủ tại chỗ của bạn yêu cầu hỗ trợ cho AES256-CBC.

3/Giải quyết

Cài đặt DST không chính xác sau khi cập nhật hệ điều hành

4/Các sự cố đã biết với bản phát hành này

Những khách hàng bị ảnh hưởng bởi thay đổi mã hóa sắp tới của Microsoft 365 AES256-CBC cần thực hiện thao tác thủ công để bật thuật toán mã hóa mới sau khi SU được cài đặt vào tháng 8 năm 2023.

5/Note

Lưu ý rằng Exchange Server 2013 KHÔNG được hỗ trợ và bạn phải nâng cấp lên Exchange Server 2019 hoặc Exchange Online càng sớm càng tốt!

https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2023-exchange-server-security-updates/ba-p/3892811

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21709

https://aka.ms/CVE-2023-21709ScriptDoc

https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-and-2016-august-8-2023-kb5029388-86b365c0-21f1-4a10-a68c-a095536f0171

https://aka.ms/ExchangeCBCKB

https://techcommunity.microsoft.com/t5/security-compliance-and-identity/encryption-algorithm-changes-in-microsoft-purview-information/ba-p/3831909

#jsisen

#viettechgroupvn

#phuongit

#exchangeserver

#phuongit

#cve202321709

#AES256CBCa

Phương nguyễn Viết

HƯỚNG DẪN CÁCH SETUP VCENTER SERVER 8.0 U1 B Step by Step

HƯỚNG DẪN CÁCH SETUP VCENTER 8.0 U1 B Step by Step

Checklist cần thiết

  • Chuẩn bị source ISO, download Vmware
  • ESXI Host,Sizing :
    • Hardware Requirements for the vCenter Server Appliance
    • Storage Requirements for the vCenter Server Appliance
  • Required Ports for vCenter Server: 902, 443, 80, 389 tham khảo tại https://ports.esp.vmware.com/home/vSphere
  • DNS Requirements for the vCenter Server Appliance, lên DNS tạo các record A, PTR
    • Name vCenter Server 8
    • vcsa.viettechgroup.lab
    • IP: 172.16.23.3
    • Host Esxi or vCenter
    • IP: 172.16.1.1
  • If you want to deploy the appliance on an ESXi host, verify that the ESXi host is not in lockdown or maintenance mode and not part of a fully automated DRS cluster
  • Stage 1 Deploy new vCenter Server: 8 Steps
  • Stage 2: Setup vCenter Server: 5 steps
  • Configure Basic vCenter Server 8

Chuẩn bị Source ISO

Cần đăng ký tài khoản Vmware để tải bản trial

https://customerconnect.vmware.com/downloads/get-download?downloadGroup=VC80U1B

Mount ISO và run Setup

Chọn Installer.exe-> Install New vCenter Server

Stage 1: Deploy New vCenter Server

Gồm 8 bước điền các thông tin như các bước chuẩn bị

B1: Introduction -> next

B2: End user license agreement-> Chọn chấp chập và next

Bước 3: Khai báo thông tin host esxi hoặc vcenter cần triển khai

Chọn Yes trust SSL

Bước 4: Khai báo VM tên và user root của VM VCSA

Bước 5: Để default tiny

Bước 6: Chọn Datastores cần Setup

Bước 7: Bước này quan trọng khai báo về port group VM network nào cần sử dụng để VM VCSA có thể liên hệ với ADDS, khi báo như hình tùy theo nhu cầu thực tế mạng của các bạn để gỏ vào.

Bước 8: chỉ là confirm các setting vừa rồi chọn finish

Chờ Install Stage1 hoàn tất

Xong stage 1 chọn -> Continues chuyển sang stage2

STAGE 2: Set up vCenter Server

Chọn next

Như vậy đã setup xong stage 2

Chúng ta có thể logon quản lý VCSA bằng cách vào

https://ip:5480

và quản lý vcenter https://ip:443 bằng vsphere client html5

Đây là quản lý máy ảo của VCSA 8 nhé

Tại đây có thể cập nhật các tùy chỉnh theo ý đồ quản trị

Lưu ý ae quản trị viên hay quên, nhớ cập nhật lại lại hệ thống password không là bị change password sau 90 ngày. 😊 Ở đây tùy ae nhé. Tôi thì có mình nên chơi never expires cho chắc ăn.

Mật khẩu vẫn để phức tạp đi

Cái quản trọng nữa là backup config sau khi cấu hình ngon lành để có trường hợp còn khôi phục lại nhé.

Còn quản lý System VM các Esxi vào https://ip

Phần 2 Cấu hình cơ bản VCSA viết sau nhé.

CÁCH CÀI SERVER ESXI VSPHERE 8.0U1 SERVER DELL EMC R750XS

CÁCH CÀI SERVER ESXI VSPHERE 8.0U1 SERVER DELL EMC R750XS

  1. CHUẨN BỊ SOURCE
  1. CÀI TỪ IDRAC LIFE CYLE CONTROLLER

Cài từ cosole của idrac

Chọn Virtual media=> connect virtual media =>mount iso vmware

Chọn ISO Vmware=> Map device

Reboot lại vào nhấn F10 vào LifeCycel controller hoặc để boot tự động sẽ vào Virtual

Chọn Virtual Keyboard-> Enter

Nhấn F11

Nhấn Enter

Nhấn Enter tiếp

Nhập password cho root

Nhấn F11 để cài

Cài thành công=> Enter để reboot tiếp tục cài

Như vậy là cài đặt xong ESXI 8.0 on Server DELL EMC R750XS

Chúc các bạn thành công

HƯỚNG DẪN CẬP NHẬT FIRMWARE BIOS VÀ IDRAC DELL EMC SERVER 750XS

Thông tin

  • Server PowerEdge R750xs
  • Bios version: 1.7.4
  • IDRAC với lifecycel controller version: 5.10.30.

Tải về

Tính đến ngày 08/05/2023 admin viết bài :

Các cập nhật thông qua web idrac

Logon vào web idrac

Kiểm tra Version

CÁCH CẬP NHẬT IRAC

Vào menu Maintance-> System Update=> Choose file

Tìm đến file Idrac và Firmware BIOS vừa download về

Chọn Upload iDRAC-with-Lifecycle-Controller_Firmware_T9J9H_WN64_6.10.30.20_A00.exe

Chúng ta nên thực hiện tuần tự upgrade idrac rồi tới Firmware BIOS nhé.

Chọn Install

Chờ reboot và cài đặt khoảng 10-15 phút

Và đây là kết quả nhé

CẬP NHẬT BIOS FIRMWARE DELL EMC SERVER R750XS

Làm tương tự như trên cho BIOS 1.9.2

Chọn install and reboot

Chờ reboot và cài lại 10-15 phút

Update thành công

Chúc các bạn thành công

Thông tin

Đối tác Google thừa nhận ‘đoán mò’ khi đánh giá độ chính xác phản hồi chatbot AI

Người dùng có lẽ sẽ suy nghĩ lại với các câu trả lời của chatbot AI, sau khi họ biết được quy trình đánh giá độ chính xác của các phản hồi này được thực hiện như thế nào.

Google đã phát hành chatbot Bard dưới dạng giới hạn vào tháng 3 vừa qua, trong nỗ lực đáp trả ChatGPT của OpenAI.

Để đánh giá chất lượng các phản hồi của chatbot AI này, công ty đã thuê một lực lượng lớn các lao động từ bên thứ ba. Tuy nhiên, các đối tác thừa nhận rằng, họ thường không có đủ thời gian để đánh giá độ chính xác của những phản hồi truy vấn này.

Appen là một nhà thầu đang giúp cải thiện chatbot Google. Các nhân viên của công ty này không được thông báo rằng nhiệm vụ của họ liên quan đến Bard, nhưng các cuộc thảo luận nội bộ về nhiệm vụ mới bắt đầu từ ngày 7/2, khoảng thời gian gã khổng lồ tìm kiếm lần đầu tiên công bố chatbot AI của hãng

Những đối tác, được gọi là “người đánh giá”, thường xem xét thuật toán tìm kiếm của Google và mức độ liên quan của quảng cáo đặt trong kết quả tìm kiếm, cũng như gắn cờ các website độc hại để chúng không xuất hiện trên trang kết quả.

Nguồn tin của Insider cho hay, kể từ tháng 1, phần lớn công việc những người đánh giá đã chuyển sang xem xét các lời nhắc của AI. Họ nói rằng không có đủ thời gian để chấm điểm độ chính xác các phản hồi con bot đưa ra, do đó đôi khi họ chỉ có thể đưa ra “dự đoán tốt nhất”.

Bard đã nhận chỉ trích sau khi mọi người phát hiện ra chatbot đưa ra câu trả lời sai ngay trong sự kiện ra mắt. Google nói rằng, chatbot sẽ trở nên tốt hơn theo thời gian và không nên coi ứng dụng này là sự thay thế cho công cụ tìm kiếm.

Trước khi ra mắt, vào tháng 2, Google cũng yêu cầu các nhân viên dành từ 2 đến 4 giờ để kiểm tra con bot, đặt câu hỏi cho nó và gắn cờ những câu trả lời không đáp ứng tiêu chuẩn của công ty.

Các nhà thầu cho biết, họ có một khoảng thời gian nhất định để hoàn thành từng nhiệm vụ, từ ít nhất là 60 giây cho đến hơn vài phút. Tuy nhiên, những người đánh giá nói rằng rất khó để đánh giá phản hồi khi họ không hiểu về chủ đề chatbot đang nói đến, trong đó có các chủ đề kỹ thuật, chẳng hạn như blockchain.

Mỗi nhiệm vụ được giao thể hiện thời gian đều tính phí, do đó các nhân viên sẽ tìm cách hoàn thành nhiệm vụ ngay cả khi họ không thể đánh giá chính xác các phản hồi chatbot đưa ra.

Những nhân viên này nói rằng, họ muốn tìm hiểu đúng sự thật và cung cấp trải nghiệm chatbot chất lượng tốt nhất có thể, nhưng đơn giản là không có đủ thời gian nghiên cứu vấn đề trước khi đưa ra xếp loại.

“Bạn cần 3 giờ nghiên cứu để hoàn thành một nhiệm vụ 60 giây, đó là vấn đề chúng tôi đang gặp phải hiện nay”, một trong những người đánh giá chia sẻ.

Nguồn Theo Insider